How to break Windows after resuming from suspending ?

NTDEV
1

For Windbg, we can break traget very early by “cycle initial break” when system boots. But if we want to break Windows as early as possible after resuming from S3, what can I do ? Any tip like "cycle initial break " ?

Thanks

2

I don’t believe that there is a WinDbg option to do this directly. I
would look at setting a break point one of the kernel functions that is
responsible for resuming the system. Unfortunately, I do not know much
about power management, so the best I can suggest is to do something
like x nt!*Hibernate* and see what you get. In particular, exactly at
what point the system is ‘resumed’ enough for WinDbg to work, I have
node idea. I suppose that it is also possible to set a breakpoint in
the ACPI code using the AML debugger extension, but I have no idea of
how to do that.

Good luck,

mm

xxxxx@msa.hinet.net wrote:

For Windbg, we can break traget very early by “cycle initial break” when system boots. But if we want to break Windows as early as possible after resuming from S3, what can I do ? Any tip like "cycle initial break " ?

Thanks

3

Please google two windbg newgroups - here and on msnews.microsoft.com,
this was discussed some time ago.

Regards,
–PA

wrote in message news:xxxxx@ntdev…
> For Windbg, we can break traget very early by “cycle initial break” when system boots. But if we want to break Windows as
> early as possible after resuming from S3, what can I do ? Any tip like "cycle initial break " ?
>
> Thanks
>

4

Thanks guys.
But I still got another problem. Because I usually debug notebooks, but almost no COM port available. I adopt 1394(onboard 1394 or 1394 express card or 1394 PCMCIA for target) debug environment on XP and Vista. But usually Windbg can’t reconnect after targets resumes from S3. This make me very confused. But for some notebooks, Windbg can work fine from S3. Does MS have any document about this issue? Personally I think this could be BIOS problem.

5

I seriously doubt that Microsoft has any documentation on this subject;
in general, documents about kernel debugging are few and far between.
Unfortunately, using WinDbg for kernel debugging of a notebook without a
serial port is a dicey proposition under the best of circumstances, and
power management is a historically atrocious feature of notebooks, not
uncommonly involving SMM/SMI, which could make this a bit of a crap
shoot, depending on vendor.

mm

xxxxx@msa.hinet.net wrote:

Thanks guys.
But I still got another problem. Because I usually debug notebooks, but almost no COM port available. I adopt 1394(onboard 1394 or 1394 express card or 1394 PCMCIA for target) debug environment on XP and Vista. But usually Windbg can’t reconnect after targets resumes from S3. This make me very confused. But for some notebooks, Windbg can work fine from S3. Does MS have any document about this issue? Personally I think this could be BIOS problem.