Jump to content


  • Content Count

  • Joined

  • Last visited

Profile Information

  • Location
  1. 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 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
  2. 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
  3. 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
  4. 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
  5. 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.
  6. 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
  7. 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, 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
  • Create New...