We're having an outbreak of DRIVER_IRQL_NOT_LESS_OR_EQUAL BSOD's in driver NETIO.SYS. Netio.sys caused BSOD's are usually tied to network drivers but that doesn't make sense because this started happening all of a sudden on multiple computers. These are fully patched/updated Windows 10 Pro computers. The common thing we're seeing is Sophos was updated to version 2022.2.1.9 around 7/20/22 on all of them. Any insight from Sophos on if the blue screen of death crashes are being caused by the latest version of Sophos?
Now (at 6 weeks since first reported), we are still affected by at least daily BSODs, although spread through different users on different hardware...
Now heavy-heartedly disabling web interception for the most heavily affected users, as I don't see any real progress here...
Support provided updated sntp.sys from Development-Team. Any experiences on trying this?
That would mean creating my own separate support case?Up to now we're just "strolling along" the existing cases and the main KB-000044389 advisory.
Our users have developer machines with 32GB RAM each which makes it kinda difficult to provide full memory dumps - even ignoring all compliancy issues there...
Does Sophos provide access to the test builds without requiring any other input data? I'd absolutely be willing to test drive that with some key users.
Yes, i'm facing this problem on Remotedesktop-Sessionhosts, 64GB RAM each. I got possible fix without providing complete memory dump. Just refer to support.sophos.com/.../KB-000044389
Active dump type would be fine. Being only Active pages it should be quite a bit smaller than 32GB. It should also zip pretty well.
I just know that in the case I opened with support, they would NOT proceed without a COMPLETE memory dump.
F Neumann I now filed our own case and inquired about getting my hands on the "potential fix".Will keep you guys posted in case I get it and on the outcome...
Thanks for chiming in so far!
Any update on this?
Well, sort of...We did file our own case on Monday and are now working through the process with a dedicated support representative.
At least for our case I can confirm that support won't hand out the patched driver without FIRST getting at least one full memory dump and the SDU logs. "Active memory dump" will be sufficient, though.
So in the meantime we have set up two of our more heavily affected users with the required settings in order to collect the required type of memory dumps.
Basically we are "waiting for BSODs" now (the same users totalled 5 BSODs together yesterday... but you know the deal with Murphy...).
Once I manage to collect and upload them, they will have a look into that - probably to verify if the case is the same one the patched driver is supposed to address.
Depending on that we'll see how this proceeds...
Thanks for the update. Then we'll have to open a case.
In the meantime we did provide two full memory dumps from two different users and machines this monday.
I did not hear back since, and we still don't have access to the test driver. I assume they are checking if our cases have the same or a similar reason, and if the test driver even addresses that same issue or not.
Also after providing the dumps I enabled the full workaround solution according to the KB for the "known-to-be-affected" users.Only to learn yesterday, that the workaround - although making the issue less frequent - does not reliably work. One of the users just had another BSOD. Thankfully he was set up to provide memory dumps, so Sophos engineers now got a 3rd full dump with SDU logs for a case that is NOT mitigated by the "turn off security" workaround.