BSOD 0x101: CLOCK_WATCHDOG_TIMEOUT

I have WDF based driver. I see a Bug Check 0x101 when I ran rebooter software with my driver installed on Vista. Bugcheck Analysis are given below

0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

CLOCK_WATCHDOG_TIMEOUT (101)
An expected clock interrupt was not received on a secondary processor in an
MP system within the allocated interval. This indicates that the specified
processor is hung and not processing interrupts.
Arguments:
Arg1: 00000061, Clock interrupt time out interval in nominal clock ticks.
Arg2: 00000000, 0.
Arg3: 803d1120, The PRCB address of the hung processor.
Arg4: 00000001, 0.

Debugging Details:

Page 4b0d3 not present in the dump file. Type ".hh dbgerr004" for details
PEB is paged out (Peb.Ldr = 7ffdf00c). Type ".hh dbgerr001" for details
PEB is paged out (Peb.Ldr = 7ffdf00c). Type ".hh dbgerr001" for details

BUGCHECK_STR: CLOCK_WATCHDOG_TIMEOUT_2_PROC

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: LogonUI.exe

CURRENT_IRQL: 1c

STACK_TEXT:
8a8076e0 828f8271 00000101 00000061 00000000 nt!KeBugCheckEx+0x1e
8a807714 828f7f7d 828e291b 000000d1 8a8077a8 nt!KeUpdateRunTime+0xd5
8a807714 828fd1ca 828e291b 000000d1 8a8077a8 nt!KeUpdateSystemTime+0xed
8a8077a8 828fc287 c0016f80 83be22f4 00000001 nt!KxFlushEntireTb+0xbc
8a8077c0 828e340b 00000003 00000001 0002381b nt!KeFlushTb+0x176
8a8077e0 828e6c54 02df0f70 6e2568a0 8a8078d4 nt!MiInitializePfn+0xa3
8a807840 8289ab54 00000001 02df0f70 00000000 nt!MmAccessFault+0x1c6c
8a807840 9bd4db73 00000001 02df0f70 00000000 nt!KiTrap0E+0xdc
8a8078d4 9bd4e53a 02df0f70 6e2568a0 00000098 win32k!memmove+0x33
8a8078f8 9bd4e443 0000001b 1163af35 8a807c38 win32k!vSrcCopyS32D32Identity+0x5b
8a807b38 9bd213d2 fe40d670 ff78a3b0 8a807b64 win32k!EngCopyBits+0x5b3
8a807ca0 9bcf9825 00000001 ff2fc388 00000000 win32k!GreSetDIBitsToDeviceInternal+0xa1d
8a807d1c 82897a1a 12010970 00000000 00000000 win32k!NtGdiSetDIBitsToDeviceInternal+0xc4
8a807d1c 772b9a94 12010970 00000000 00000000 nt!KiFastCallEntry+0x12a

STACK_COMMAND: kb

SYMBOL_NAME: ANALYSIS_INCONCLUSIVE

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Unknown_Module

IMAGE_NAME: Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP: 0

FAILURE_BUCKET_ID: CLOCK_WATCHDOG_TIMEOUT_2_PROC_ANALYSIS_INCONCLUSIVE

BUCKET_ID: CLOCK_WATCHDOG_TIMEOUT_2_PROC_ANALYSIS_INCONCLUSIVE

Followup: MachineOwner

I saw messages in bugcheck analysis
Page 4b0d3 not present in the dump file. Type ".hh dbgerr004" for details
PEB is paged out (Peb.Ldr = 7ffdf00c). Type ".hh dbgerr001" for details

When I ran ".hh dbgerr001", WDk documentation says that when this error occurs, it means that the debugger has detected that the PEB data structure for this process is no longer readable. Most likely, is has been paged out to disk. Without this data structure, the debugger cannot determine what images the symbols should be loaded for.

Also there is a note saying this only affects symbol files for the user-mode modules. Kernel-mode modules and symbols are not affected, as they are tracked in a different list.

My question is does this happen because of some user-mode module? Or memory management in my driver went wrong?

>

I have WDF based driver. I see a Bug Check 0x101 when I ran rebooter
software
with my driver installed on Vista. Bugcheck Analysis are given below

0: kd> !analyze -v

************************************************************************
******

*
*
*
* Bugcheck Analysis
*
*
*

************************************************************************
******

*

CLOCK_WATCHDOG_TIMEOUT (101)
An expected clock interrupt was not received on a secondary processor
in an
MP system within the allocated interval. This indicates that the
specified
processor is hung and not processing interrupts.

This may be completely unrelated, but are you running in a virtual
environment? The nature of virtualisation is that you see this crash
sometimes under load unless you tell the kernel that it is being
virtualised and it turns off (or relaxes?) the timeout.

James

It’s probably a different processor that’s hung and this processor just
happened to be the one to notice. Try !running -ti and see what the other
processors are up to.

-scott


Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@ntdev…
>I have WDF based driver. I see a Bug Check 0x101 when I ran rebooter
>software with my driver installed on Vista. Bugcheck Analysis are given
>below
>
> 0: kd> !analyze -v
> ***
> *
>
> * Bugcheck Analysis
>
> *
>
>

>
> CLOCK_WATCHDOG_TIMEOUT (101)
> An expected clock interrupt was not received on a secondary processor in
> an
> MP system within the allocated interval. This indicates that the specified
> processor is hung and not processing interrupts.
> Arguments:
> Arg1: 00000061, Clock interrupt time out interval in nominal clock ticks.
> Arg2: 00000000, 0.
> Arg3: 803d1120, The PRCB address of the hung processor.
> Arg4: 00000001, 0.
>
> Debugging Details:
> ------------------
>
> Page 4b0d3 not present in the dump file. Type “.hh dbgerr004” for details
> PEB is paged out (Peb.Ldr = 7ffdf00c). Type “.hh dbgerr001” for details
> PEB is paged out (Peb.Ldr = 7ffdf00c). Type “.hh dbgerr001” for details
>
> BUGCHECK_STR: CLOCK_WATCHDOG_TIMEOUT_2_PROC
>
> DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
>
> PROCESS_NAME: LogonUI.exe
>
> CURRENT_IRQL: 1c
>
> STACK_TEXT:
> 8a8076e0 828f8271 00000101 00000061 00000000 nt!KeBugCheckEx+0x1e
> 8a807714 828f7f7d 828e291b 000000d1 8a8077a8 nt!KeUpdateRunTime+0xd5
> 8a807714 828fd1ca 828e291b 000000d1 8a8077a8 nt!KeUpdateSystemTime+0xed
> 8a8077a8 828fc287 c0016f80 83be22f4 00000001 nt!KxFlushEntireTb+0xbc
> 8a8077c0 828e340b 00000003 00000001 0002381b nt!KeFlushTb+0x176
> 8a8077e0 828e6c54 02df0f70 6e2568a0 8a8078d4 nt!MiInitializePfn+0xa3
> 8a807840 8289ab54 00000001 02df0f70 00000000 nt!MmAccessFault+0x1c6c
> 8a807840 9bd4db73 00000001 02df0f70 00000000 nt!KiTrap0E+0xdc
> 8a8078d4 9bd4e53a 02df0f70 6e2568a0 00000098 win32k!memmove+0x33
> 8a8078f8 9bd4e443 0000001b 1163af35 8a807c38
> win32k!vSrcCopyS32D32Identity+0x5b
> 8a807b38 9bd213d2 fe40d670 ff78a3b0 8a807b64 win32k!EngCopyBits+0x5b3
> 8a807ca0 9bcf9825 00000001 ff2fc388 00000000
> win32k!GreSetDIBitsToDeviceInternal+0xa1d
> 8a807d1c 82897a1a 12010970 00000000 00000000
> win32k!NtGdiSetDIBitsToDeviceInternal+0xc4
> 8a807d1c 772b9a94 12010970 00000000 00000000 nt!KiFastCallEntry+0x12a
>
>
> STACK_COMMAND: kb
>
> SYMBOL_NAME: ANALYSIS_INCONCLUSIVE
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: Unknown_Module
>
> IMAGE_NAME: Unknown_Image
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 0
>
> FAILURE_BUCKET_ID: CLOCK_WATCHDOG_TIMEOUT_2_PROC_ANALYSIS_INCONCLUSIVE
>
> BUCKET_ID: CLOCK_WATCHDOG_TIMEOUT_2_PROC_ANALYSIS_INCONCLUSIVE
>
> Followup: MachineOwner
> ---------
>
> I saw messages in bugcheck analysis
> Page 4b0d3 not present in the dump file. Type “.hh dbgerr004” for details
> PEB is paged out (Peb.Ldr = 7ffdf00c). Type “.hh dbgerr001” for details
>
> When I ran “.hh dbgerr001”, WDk documentation says that when this error
> occurs, it means that the debugger has detected that the PEB data
> structure for this process is no longer readable. Most likely, is has been
> paged out to disk. Without this data structure, the debugger cannot
> determine what images the symbols should be loaded for.
>
> Also there is a note saying this only affects symbol files for the
> user-mode modules. Kernel-mode modules and symbols are not affected, as
> they are tracked in a different list.
>
> My question is does this happen because of some user-mode module? Or
> memory management in my driver went wrong?
>

Scott,

Could you please provide more details on “ti” command. I am not able to run it on WinDbg.

Snoone recommended that you use the ‘!running’ command with the ‘-ti’ option, not the ‘ti’ command (which doesn’t exist).

It’s in the docs.

Good luck,

mm

Scott Noone wrote:

It’s probably a different processor that’s hung and this processor just
happened to be the one to notice. Try !running -ti and see what the other
processors are up to.

Jeez, another Windbg command I’d never heard of. Its starting to seem
like that program can do everything except make the coffee, if you can
only figure out the random sequence of character to invoke the command.

One of the things I really liked about SoftIce was discoverability: when
you typed a few characters of a command, it showed you the possible
completions in its status bar. That was a bright shining model of
discoverability. With Windbg, it’s a little walking into a huge library
where all of the books are in a pile on the floor. The answer is in
there, somewhere…


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Pressing [Tab] in windbg does command completion too.

Typing

!r tab tab tab

gives you the suggestions

!rtlavl
!rebase
!range
!rawrange
!ready

!running


Jon

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, August 28, 2009 10:09 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] BSOD 0x101: CLOCK_WATCHDOG_TIMEOUT

One of the things I really liked about SoftIce was discoverability: when
you typed a few characters of a command, it showed you the possible
completions in its status bar. That was a bright shining model of
discoverability. With Windbg, it’s a little walking into a huge library
where all of the books are in a pile on the floor. The answer is in
there, somewhere…


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Tim Roberts wrote:

Jeez, another Windbg command I’d never heard of. Its starting to seem
like that program can do everything except make the coffee, if you can
only figure out the random sequence of character to invoke the command.

Windbg must be TECO reborn!

I must try typing in my name next time I’m debugging something…

– mkj


//
// Michael K. Jones
// Stone Hill Consulting, LLC
// http://www.stonehill.com
//_______________________________________________

In addition to tab completion, the bang commands are all just exports of
DLLs so you can get your authoritative list by dumping the exports of the
various extension DLLs. Not saying that they all work or are documented, but
running through them can be a useful exercise on a rainy Friday afternoon.

And I believe !makethecoffee is on the feature list (along with !fixthebug)

-scott


Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@ntdev…

Pressing [Tab] in windbg does command completion too.

Typing

!r tab tab tab

gives you the suggestions

!rtlavl
!rebase
!range
!rawrange
!ready

!running


Jon

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, August 28, 2009 10:09 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] BSOD 0x101: CLOCK_WATCHDOG_TIMEOUT

One of the things I really liked about SoftIce was discoverability: when
you typed a few characters of a command, it showed you the possible
completions in its status bar. That was a bright shining model of
discoverability. With Windbg, it’s a little walking into a huge library
where all of the books are in a pile on the floor. The answer is in
there, somewhere…


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Funny you should mention that, as (perhaps lesser known), WinDbg does actually have tab completion for extension commands in already-loaded extension modules.

(No fancy list of all possible completions without cycling through however.)

But I suspect the real reason re: the lack of discoverability is that most of the folks who write extensions do so to help them solve a specific problem that they are working on right now, and that is often not an environment conducive to writing lotsa documentation.

At least, that’s often been my personal story with any extensions that I have written to solve a specific, immediate problem. If you’re lucky, they show up with a one-liner in !mydll.help :slight_smile:

  • S

-----Original Message-----
From: Tim Roberts
Sent: Friday, August 28, 2009 11:06
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] BSOD 0x101: CLOCK_WATCHDOG_TIMEOUT

Scott Noone wrote:
> It’s probably a different processor that’s hung and this processor just
> happened to be the one to notice. Try !running -ti and see what the other
> processors are up to.
>

Jeez, another Windbg command I’d never heard of. Its starting to seem
like that program can do everything except make the coffee, if you can
only figure out the random sequence of character to invoke the command.

One of the things I really liked about SoftIce was discoverability: when
you typed a few characters of a command, it showed you the possible
completions in its status bar. That was a bright shining model of
discoverability. With Windbg, it’s a little walking into a huge library
where all of the books are in a pile on the floor. The answer is in
there, somewhere…


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer