Key: HKLM\System\CurrentControlSet\Services\i8042prt\Parameters
Value: CrashOnCtrlScroll (DWORD) set to 1 (add it if it does not exist)
Press CTRL+Print Screen[Sys Rq] twice in succession to generate a
BugCheck event.
I believe this information is well known: I read something about it
(though
I can’t seem to remember the page, I’ve looked but did not find it) on
Edward N. Dekker’s book “Developing WinNT Device Drivers”
(Addison-Wesley, 1999). This book was targeted to NT 4 and introduced
some concepts on WDM (Win2K was in a beta-testing stage then), but
I’m sure it mentioned this feature somewhere in the first chapters.
«Humour and love are God’s answers
to Human weaknesses»
Nate Bushman wrote:
Elyias just informed me that:
This break point is intentional. Useful for debugging hung systems.
It’s on by default on a checked build system. You can turn that off
by
setting BreakOnSysRq DWORD to 0 under the Parameters of i8042prt
service
key.
It did seem to be a pretty nifty “bug” at first. Enough so that I
wondered
if it was intentional. But, I’d never heard or seen anything about
this
issue. Is it documented?
Ed Lau wrote:
Better yet, change the value of
“HKLM\System\CurrentControlSet\Services\i8042prt\Parameters”,
CrashOnControl (a DWORD) to 1 (add it if it does not exist) and press
right-control and print screen twice in succession - you’ll generate a
STOP
with the message “The end-user manually generated a crash dump”. This
is
an intentional feature, by the way. It is usefull if the kernel or a
device driver
has become deadlocked, for instance.
this is documented in KB Q244139
The value is “CrashOnCtrlScroll”; i had a typo in the last post as well
Maxim S. Shatskih wrote:
When you have KD attached to the machine, pressing SysRq (aka
PrintScreen)
on it has exactly the same effect as Ctrl-Break in KD/WinDbg, though
works
more reliably.
This is by design and was described in NT4 DDK.
Phil Barila wrote:
That happens if you press PrintScreen, without the control key, also.
Strange thing, I expected it to happen if I did an [ALT]+PrintScreen,
and
that does not happen. So whatever codes the debugger is catching, it
doesn’t include the one I expected.
-----Original Message-----
From: Nate Bushman [mailto:xxxxx@Legato.com]
Sent: Friday, May 11, 2001 9:25 AM
To: NT Developers Interest List
Subject: [ntdev] Here’s a fun one for ya…
Reproducable on W2K SP1 (I haven’t bothered to check the other
variations)
If you have a kernel debugger hooked up to a target machine, and you hit
CTRL-PrtScn on the target machine, the driver that handles that
interrupt,
i8042prt.sys, will issue a hard breakpoint, which you’ll see over in the
debugger.
Neeto!!
Here’s the stack after it hits the hard breakpoint when I’ve typed
CTRL-PrtScn
on the target machine:
ChildEBP RetAddr Args to Child
804712a4 edc820d4 00000002 817c6368 817d2480
ntoskrnl!RtlpBreakWithStatusInstruction (FPO: [1,0,0])
8047130c 80466eca 817c6368 817d23c0 80471302
i8042prt!I8042KeyboardInterruptService+0x425 (FPO: [Non-Fpo])
8047130c 80069a26 817c6368 817d23c0 80471302
ntoskrnl!KiInterruptDispatch+0x2a (FPO: [0,2] TrapFrame @ 80471324)
80471394 804621b9 0000000e 00000000 00000000
halaacpi!HalProcessorIdle+0x2
(FPO: [0,0,0])
ffdff800 ffdff800 00000000 00000000 0024ef94 ntoskrnl!KiIdleLoop+0x10
I emailed xxxxx@microsoft.com about this. I dunno if that’s the right
place
to report this issue. Anyone know?
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com