Mpeter

I've sent you the link

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

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

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

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

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.

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

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

Thank yor for all of your responses. I'll try this, but first I'll go through the other 2 answers. I've blocked DNS (port 53, TCP and UDP) on direction "out" again. nslookup does not work as expected, but after starting a Wireshark capture there are still queries and responses going on port 53 as you can see here. DNS queries triggered by Firefox (e.g. by loading a page) get through too. I'll try what happens when I move rules above the hidden ones. As I said in the original post, I'm blocking DNS for testing purposes, as it is used so much that if it gets blocked properly then it will be easy to see

I've been trying to configure my firewall to my taste for some time already, but it seems I've difficulties setting it up properly. Recently I've reinstalled Eset in English language, so I can see if something is translated wrongly, and you can help easier this way too. I assume, as your documentation states, that the rules are processed from the top to the bottom. I also assume that the first rule's action that fits a packet is applied to it, and evaluation of following rules will not happen. Please correct me if some of the assumptions are incorrect. I use automatic mode, and I did not modify the hidden rules, or if I did I did so with an other setting which is not in the firewall section. You can see my current rules on the first image. Before following, please not the first and last rules: the first one is there for testing purposes only. I'll talk about it below. the last one is to notify me with a popup in the bottom left if there are any unexpected incoming connections, and also if rules are not working as I expect I noticed the following anomalies: see the second rule from the end, named "Silent block Windows Connected Devices sync broadcasts". I placed it there so when a phone on my network communicates with the PC it's sync is set up with (it's an other one) then I won't get a notification about that. this service for some reason communicates with broadcasts through port 5050. Now take a look at the second picture. Here you can see that the above mentioned service's communication is not blocked by that rule, but rule evaluation is reaching the last rule, which blocks everything else and notifies me. My question is why doesn't the mentioned rule (2nd from the bottom) block the communication? If the first rule (named DNS deny) is turned on, DNS requests made with the nslookup command are blocked, but DNS requests made in any other way (Firefox browser (DOH is disabled), Windows service Dnsclient) are not, and I can even see them in a Wireshark capture, both the query and the response? see the third rule allowing any communication for qBittorrent. Sometimes I get log entries that the last rule (named Anything) blocks inbound communication for it. why isn't rule evaluation stop at the third rule, with the conclusion that this communication is allowed? that rule has an application filter, but the filter points to the executable that is trying to receive the connection. Please note that the logs on the second image only include entries for the first point. This happens quite frequently if certain conditions met, and a few minutes earlier I deleted all networking logs to make sure they don't make any confusion. If you need further information feel free to ask. If you provide instructions I can export these rules and upload them here so you can see a few details that are not seen in the list.