Connecting windbg and looking at stack trace shows this:

0: kd> kn
# ChildEBP RetAddr
00 818f1ca8 818d69f4 nt!RtlpBreakWithStatusInstruction
01 818f1cb0 818285e5 nt!KdCheckForDebugBreak+0x22
02 818f1cd0 8189056d nt!KeUpdateRunTime+0x270
03 818f1cd0 81bb42a6 nt!KeUpdateSystemTime+0xed
WARNING: Frame IP not in any known module. Following frames may be wrong.
04 818f1d50 81891272 0x81bb42a6
05 818f1d54 00000000 nt!KiIdleLoop+0xa

The current workaround to get across this hang has been to hit a "g", kill
windbg and restart fresh windbg session. "Just hitting go" doesnt seem to
help.
Has anyone see similar problem? Does anyone know the problem/solution apart
from this workaround?

Regards,
-Praveen

On my systems, crcdisk just happens to be the last loaded boot driver. A
hang at that point is usually not related to crcdisk.

I have experienced similar hangs in the past:
1. When a debugger is attached to the serial line of the hung system, some
times it helps to reduce the debugger's baudrate.
2. On some of my systems, swicthing from COM debugging to 1394 debugging
helped get rid of the boot hangs.
3. Other times one of the boot drivers is really hung. !locks in the
debugger can reveal one of the PnP locks being held by a thread that is
stuck in a driver.
Bottom line is that each hang can be different and has to be figured out
individually. I don't remember to have ever seen one that was related to
crcdisk though.

Dan

--
This posting is provided "AS IS" with no warranties, and confers no rights.


"Praveen Kumar Amritaluru" <apraveen.kumar@gmail.com> wrote in message
news:%23$lwLdUVHHA.972@TK2MSFTNGP04.phx.gbl...