Comments

@android: I don't know how it got changed, but Occam's razor says that I probably unchecked the box at some point in the past without realizing it.

Incidentally, this behavior is not specific to Windows 8. You can turn off "Find partial matches" in the Windows 7 search options and see the same behavior when searching from the start menu.

@Dark_Halmut: Cool, good to hear you got it worked out. I wonder if there's a bit more RF interference causing problems when it's in the back port, or something to do with the position of the antenna.

We now have a KB article published which explains the monitor timeout at lock screen issue [07:57].

Monitor powers off after 1 minute when PC is locked

@Emkay1001: Right, it is the console lock timeout, which is separate from the regular video idle timeout. The "Turn off the display" setting in the Power control panel allows you to adjust the video idle timeout, but the timeout when on the lock screen (which defaults to 1 minute) is not adjustable via the GUI.

You don't need to add any special registry hacks to adjust the lock screen display timeout, though. You can do it via an elevated command prompt using the following commands:

powercfg /setacvalueindex SCHEME_CURRENT SUB_VIDEO VIDEOCONLOCK <time in seconds> 
powercfg /setactive SCHEME_CURRENT 

This would set the console lock timeout for when the system is on AC power. To change it for the battery power profile (I wouldn't recommend this), use "/setdcvalueindex" instead.

@FFE: You got it! I set the breakpoint on the dispatch routine for IRP_MJ_POWER (modem!ModemPower), then disabled the modem in device manager, which would result in, not a power IRP, but a Plug and Play IRP (IRP_MJ_PNP).

I should have set the breakpoint on modem!ModemPnP instead of modem!ModemPower.

Brownie points to the first person who can tell me why my modem.sys breakpoint didn't get hit! I went back and watched the show later and figured out my mistake.

@dcrearer: Sorry, I didn't see this question earlier.

The !d commands (!db, !dc, !dd, etc.) take a physical memory address as the parameter. The regular d commands (db, dc, dd, etc.) take a virtual address. Other than that, they are the same.

@MagicAndre1981: Yes, I've asked. A few of the newer bugchecks have been added to the documentation, but it's not clear every single one needs to be added. A lot of these bugchecks are rarely, if ever, seen in the wild. If there are specific ones that need to be documented, we can ask for them.

@MagicAndre1981: Did you try adding the DedicatedDumpFile setting?

Yeah, it looks like the people in charge of maintaining the debugger help file haven't gotten around to documenting all those newer bugchecks. Bugcodes.h contains the most definitive list of codes used by Windows components. Of course, third-party drivers are free to use any bugcheck code they want.

@dcrearer: I don't have a 6th Edition Windows Internals handy at the moment, but in my 5th Edition copy, there is a chart of the x64 address space layout, so hopefully it's still there!

On x64, user process address space is 0x0000000000000000 - 0x000007FFFFFEFFFF (8TB minus 64KB).
System space is from 0xFFFF080000000000 - 0xFFFFFFFFFFFFFFFF.

We will do more episodes on debugging. Thanks for watching!