ADB-like thing for Windows 10?

Question

My actual aim is to find out what causes freezes occurring on a HP ProBook 450 G3 about once in a week (no reaction to any keystrokes except power button; however there is obvious activity, and the cooler actually becomes more active than on average). But I realize that in this form the question is hopelessly general, there might be dozens of very different reasons. So I decided to ask specifically whether there is some tool that I could use to peek inside the system - find out which processes are running, etc.

If it would be, say, an android tablet, I would know what to try: connect it via usb to a healthy computer and run adb; if the device is visible, I could then use logcat.

So my question is only this: is there some tool similar to adb that would work between, say, two Windows systems?

One related question I found here is Using WinDbg to "break into" a badly hung kernel crash and see what's gone on?; it has no answer but inside the question itself WinDbg is mentioned. If I understand correctly this would not help here, since WinDbg is installed and run on the same machine. Or is there a way to use WinDbg as a debug bridge between two machines?

Another related question is How to find the culprit that freeze windows 10 when task manager is also frozen (till windows unfreezes)?, it has one answer but this would not help me either - it suggests something like running Task Manager all the time, i. e. does not involve other computer, and would be impractical for freezes that occur very infrequently.

Answer 1

The answer depends on what you're looking to do:

Userspace — If the OS is alive but video output is stuck

ADB still generally requires the target device to have a working OS – such things as adb shell or adb logcat really just connect to a special app that lets you inspect other app-related things.

Similarly, if your Windows OS is still able to receive network connections and start new processes, you have several services which can provide standard command-line access:

• SSH – OpenSSH comes by default with recent Windows 10 versions and is easy to enable. (For older versions, Bitvise WinSSHD is the least annoying alternative.) You can connect using the ssh command or using PuTTY.

• PowerShell has PS-Remoting, which is a bit more cumbersome to set up and generally requires another Windows system to connect.

• There are also various semi-legacy DCOM RPC interfaces which let you run list processes on a remote system (qprocess /server:<target> or tasklist /s <target>) or access the Event Log (eventvwr.msc has "Connect to another computer") or various other management tasks.

(There is of course the graphical Remote Desktop, but due to the way it works – by detaching the entire desktop from the GPU when you connect via RDP – it's probably not a good debugging tool in your situation.

On the other hand, there's also a hidden shortcut WinCtrlShiftB which attempts to reset the GPU driver in case that's the only issue.)

Kernelspace — If you're certain that the OS is completely hung

If the OS is completely wedged, remote kernel debugging is not a new thing. (It's an integral part of driver development, I would assume.) I have no experience with this whatsoever, but see this section on Microsoft Docs for various ways to attach a debugger running on a second system to your OS.

(For example, the linked post makes a guess that FireWire (IEEE 1394) – which once was a more powerful competitor to USB – could be abused for this through its DMA support. And indeed, Windows has for a long time supported 1394 debugging connections, although this was removed recently as the hardware support is getting rare.)

It seems from the website that the preferred method is via Ethernet, as long as the driver on the debugged system supports this function. Other methods listed on that site are serial (if you had a desktop PC with a "COM1" pin header) or USB (which requires a specially wired cable).