Multiple PCs frozen right after update.

Our customer has same problem with  HP Compaq 8100 Elite CMT PCs since October, and now they find that the freeze often occurs when Google Chrome is opened.

The same, it will not freeze after removing Sophos Endpoint.

I'm glad I'm not the only one, though it doesn't seem to matter whether chrome is involved or not.  So far the majority of the computers that have been crashing are just used for RDP and nothing else because of their age.     

Are you able to force a complete or active dump of the computer when in the hung state? Say 30 seconds after it's hung? This is the information of most use here I would say. 

Turned on the dump on power off, but the last couple computers that crashed with didn't dump anything.  I noticed the event log lists that the unexpected shutdown is always at the time of the freeze rather than when it's actually powered off.    

Maybe try the crash on ctrl scroll option, or change the keys if you don't have a scroll lock. A complete dump is the best way forward for a hang otherwise you could be trying settings for weeks if it's not reproducible. 

No dice with that either.  Computers are completely unresponsive and take no input.  The event log considers them shutdown in this state even when they are still technically on.

Our customer's computers didn't dump anything too, even keyboard force dump. 

Our customer's computers didn't dump anything too, even keyboard force dump. 

The other option is to involve another computer and try setting up kernel debugging over the network as detailed here:

Setting Up KDNET Network Kernel Debugging Manually - Windows drivers | Microsoft Docs

Essentially you get the IP address of the "good" machine you're going to connect from with WinDbg. E.g. 192.168.1.5

On the target computer to be debugged, the failing computer in this case, run the following in an admin prompt:

bcdedit /debug on

bcdedit /dbgsettings net hostip:192.168.1.5 port:50000

This will print you a key you need to copy to the "good" computer.

You can then launch Windbg on the "good" machine, choose Kernel Debugging and use the Key under the Net type.

It will try and connect,  If you reboot the target, so the bcdedit commands take, when it comes back up you should be connected to it in WinDbg from the good computer.

When the "target" computer has the issue, when connected, you can run ".crash" in Windbg to bugcheck the "bad" computer.  This should create a MEMORY.DMP dump under \windows\ on the bad computer.  Ensure it's set to create a complete or active dump.

Maybe this could work?

I'm attempting this now on one of the more problematic computers.  I've had it running in debug for five days and it hasn't crashed yet, so a bit frustrating.  Thought maybe it could be a corrupted user profile, but this has happened to freshly imaged computers also.

Hi Sophos User5115

Good day, have you successfully got the dump?

I found our customer's affect computers (6 HP Compaq 8100 Elite CMT PC + 1 ASUSPC) all have Broadcom Netxtreme drivers b57nd60a, ebdrv, b06bdrv , where b57nd60a is same with yours, but all of them have no actual Broadcom Netxtreme Network card hardware on the computer, only drivers placed in the system by the manufacturer, you can not see them in the Device Manager but you can see them in the msinfo32.exe and C:\Windows\System32\drivers.

They had tried to rename these driver''s extension from .sys to .old in C:\Windows\System32\drivers to unload them few days ago, but the freeze still occurred that time.