Unable to boot after major update

[Mpeter 0]

Earlier I got a notification that ESET needs a reboot to install it's new major update (to version 13). I wasn't able to reboot at that time because I was working on my computer, and since I always hibernate it to save time and the state of all the opened programs, I quickly forgot that I should reboot my PC.

Last week came the time that I needed to reboot my PC. Since that, I'm unable to boot into the system. I get a BSOD with the stop code of PROCESS1 INITIALIZATION FAILED every time. I don't get any dump files, probably because I set the pagefile to be on an other drive, but fortunately I'm able to start Windows with debugging enabled, and do debugging with WinDBG from my laptop through the network. More on the BSOD later.

Before continuing I want to let you know that I have backups which I can restore, but even the oldest one isn't old enough to be working. The point is, that the system can be restored to a point when it wasn't altered by my attempts to fix it. I regularly do that whenever I feel that that I'm in a dead end, to avoid the situation where more of my modifications are contributing to an ever worse problem

Back to the point:
I suspect it's ESET blocking file system access from the system for 2 reasons: first, if I enable boot logging then the ntbtlog.txt does not get created in C:\Windows\, neither if I do it temporarily from the special boot options, nor when I set bootlog to yes with bcdedit. and second, because there are files in C:\Program Files\ESET\ that are from an older version, like \Eset\Eset Security\Drivers\eelam\eelam.sys is a version of 10.0.9.0, according to the system's properties dialog, while most of the other files are from 10.13.*.*. However, I'm unable to boot even to safe mode, because the same error happens, so I'm unable to remove ESET with your tools. Also, I had such a problem a few years earlier too. I don't know how did I solve that, but I know that it wasn't an OS reinstallation.

At the moment I can only make complete memory dumps (in WinDBG), but I'll try to convince the OS to make kernel memory dumps

###############################

Details about the BSOD

STOP code: PROCESS1 INITIALIZATION FAILED
1st param: 0xFFFFFFFFC0000279 (STATUS_IO_REPARSE_TAG_NOT_HANDLED ?)
2nd param: 0x0000000000000002 (undocumented, but probably ntdll.dll being inaccessible, source is in a feedback of the STOP code documentation)
3rd param: 0x0000000000000000
4th param: 0x0000000000000000

The output of a few informative commands that I ran in WinDBG is attached to this post. It includes the output of !analyze -v, !analyze -hang, and lm
Later I'll include the kernel dump if I can obtain one

Both the output of the commands I ran in WinDBG, and that while booting, at one point the HDD led starts blinking not randomly, but periodically like retrying after a timeout, seems to confirm that the system may not be able to read ntdll.dll or an other such file.
Looking at the properties window of ntdll.dll and a few other related files (which were mentioned in the WinDBG output) shows that it's signature is valid, so if I'm not wrong, that should mean that the files are intact.

Could you help to identify and fix the problem? I can provide you with anything that you ask, but I feel that I'm too little to fix such a problem by myself. I have ideas on what to look into, but there's too much things, and even then I don't know how will I check if it's because of ESET or not, or what do I do if I find that the file that it tries to access is actually intact

 

Sorry if I've written a lot, I just wanted to give the related information that I've found to possibly boost finding a resolution. Maybe you see how desperate I'm to recover the system if I've gone to such lengths to obtain information.

debugger results.txt

[itman 1,659]

Boot into Win 10 Recovery Environment from installation media. Then run Start Up Repair and see if that allows you to boot into Win 10 normally.

[Mpeter 0]

Thank you for your reply!

It does not. In C:\Windows\System32\LogFiles\Srt\SrtTrail.txt it will only write that "A recently serviced boot binary is corrupt.", no other details, except the performed checks which all has a return value of 0

[itman 1,659]

First,from Recovery Environment access Command Prompt option. Enter the following:

bootrec /rebuildbcd

Now try to boot.

If the above doesn't work, you can try System Restore option from Win 10 Recovery Environment. Don't know when your last Restore point was taken but at least this might get your system to boot.

[Mpeter 0]

I've already tried bootrec /rebuild bcd, it didn't solve the problem. Also, it seems like the system actually gets through that part.

I don't have system restore points.

[Marcos 5,074]

Please drop me a private message with a download link to the memory dump.

[Mpeter 0]

Ok, I may have not included 2 important details, to not make this too complicated for the first sight. I mean, the first post was long enough even this way. Also, I left them out because I've already dealt with them. After temporarily convincing the system that there are no pending actions, I was able to use dism and sfc to verify system files, and these said that the system files are OK. So after that, I can only think of a configuration problem (but what and how?), and that something with an FS UpperFilter driver denies access to system files after that driver has been loaded

First, there is a pending Windows Update, waiting to install. Its from 18362.719 to .720.
Theoretically it shouldn't be a problem, but something must have caused it. I don't want to go much into that because that's out of the scope of this forum, but I've got the update packages for .719 and .720 on my pendrive along with the latest servicing stack update. removing the package of .720 and re-adding the package of .719 does not (seem to) help, nor does it help to add the package of 720, or a never version, because every package addition/removal will just be prepared while the system is offline, and it needs to be integrated on boot

Second, that last restart was actually a crash, but considering what I had running at the time it's 95% that the system ran out of memory. Maybe it has been logged in the event logs, but I don't think I can access it from outside of the system

[Mpeter 0]

6 minutes ago, Marcos said:

Please drop me a private message with a download link to the memory dump.

I'm currently restoring the system from backup, but afterwards I will do. Thank you!

Should I try to have a kernel memory dump, or it will be okay if I can give a complete memory dump?
Not sure if there are major differences, because when the BSOD happens there are only kernel code running anyway

Edited May 13, 2020 by Mpeter

[Marcos 5,074]

We will prefer a complete memory dump.

[itman 1,659]

33 minutes ago, Mpeter said:

So after that, I can only think of a configuration problem (but what and how?), and that something with an FS UpperFilter driver denies access to system files after that driver has been loaded

Eset's ELAM driver is the first non-device kernel driver to load. It's primary purpose is to inspect all drivers that load after it. Once that is completed, Eset's ELAM driver unloads itself and the boot process continues.

If Eset's ELAM driver became "hosed" in some fashion, it could definitely screw up booting.

[Mpeter 0]

37 minutes ago, Marcos said:

We will prefer a complete memory dump.

Thank you, I'll send you a dump tomorrow. That restore won't complete today. Tried out if a clean system can boot, just to be sure, and now it can't use it's speedup techniques

[Mpeter 0]

22 minutes ago, itman said:

Eset's ELAM driver is the first non-device kernel driver to load. It's primary purpose is to inspect all drivers that load after it. Once that is completed, Eset's ELAM driver unloads itself and the boot process continues.

If Eset's ELAM driver became "hosed" in some fashion, it could definitely screw up booting.

Actually that one seemed to be versioned completely differently. I can't see the file now because of the restore, but I remember that while most of the other files were versioned as 10.13.*.*, that one (it's .sys file) was on 10.0.9.0. Can that be a problem, or you just rarely update that one?
If I remember correctly, the signatures were ok according to the system

If that file is ok, it may be worth to check other critical files of ESET, though, if there are

But actually I'm not sure if really that driver is the problem. I've tried to boot multiple times with the option "disable early launch anti-malware protection", but nothing changed

Edited May 13, 2020 by Mpeter

[Mpeter 0]

20 hours ago, Marcos said:

Please drop me a private message with a download link to the memory dump.

I've sent you the link