Note: this content originally from http://mygreenpaste.blogspot.com. If you are reading it from some other site, please take the time to visit My Green Paste, Inc. Thank you.

Just a quick note - the authors of Advanced Windows Debugging have been interviewed on MSDN's Channel 9. It's about 43 minutes long, and it's interesting to hear the authors talk about their experiences, the motivation behind the book, the effect of additional layers of abstraction, etc., and go through a handle leak debugging session. Check it out!

Note: this content originally from http://mygreenpaste.blogspot.com. If you are reading it from some other site, please take the time to visit My Green Paste, Inc. Thank you.

Previously, I had written about the puzzlers on the NTDebugging / Microsoft Advanced Windows Debugging and Troubleshooting blog - specifically, the most recent puzzler which involved reverse engineering some assembler. The answer was posted today - there were a lot of responses, and a lot of correct responses.

I had posted the hashes for my answer (which was correct), that I am now able to disclose...

void myfun( char* param1 )
{
    size_t local1 = strlen( param1 );
    for( int local2 = local1; local2 > 0; local2-- )
    {
        for( int local3 = 0; local3 < local2 - 1; local3++ )
        {
            if( *(param1+local3) > *(param1+local3+1) )
            {
                char local4 = *(param1+local3);
                *(param1+local3) = *(param1+local3+1);
                *(param1+local3+1) = local4;
            }
        }
    }
}

Note: this content originally from http://mygreenpaste.blogspot.com. If you are reading it from some other site, please take the time to visit My Green Paste, Inc. Thank you.

Over on the Microsoft Advanced Windows Debugging and Troubleshooting blog, they've been posting a "Puzzler" every Monday and providing the answers the following Friday.

The puzzlers are fun to participate in and it is interesting to read people's responses - everyone has their own ideas and own experiences to draw off of.

With the third puzzler, the blog authors have decided to make the challenge a bit more difficult - the latest puzzler requires one to reverse engineer some assembler.

I've not got much experience with reverse engineering assembler - I can read some assembler and can usually get a very basic idea of what a targeted chunk of code is doing. So it was an interesting challenge for me to attempt to C-ify the assembler they provided. It doesn't appear that the authors are posting the responses until they reveal the answer (makes sense to me!). But I thought I'd post hashes of my response, which I'll also post once the NT Debugging blog authors post the answer and submitted comments / responses.

From Sigcheck:

Z:\NTDebuggingPuzzler3>sigcheck -h TheFunc.txt

Sigcheck v1.52
Copyright (C) 2004-2008 Mark Russinovich
Sysinternals - www.sysinternals.com

Z:\NTDebuggingPuzzler3\TheFunc.txt:
Verified: Unsigned
File date: 12:52 PM 4/22/2008
Publisher: n/a
Description: n/a
Product: n/a
Version: n/a
File version: n/a
MD5: 755394f9711b80968f17c8ffcb8f2394
SHA1: e8443f09eef43f2575aa08ba25f68267dba7243e
SHA256: 0e044419ef78f2fa7a8e258098f4f658426a8dc3e8a5b9a121a352c2dbbbfafc

After the previous BSOD in Vista, I logged in to Vista interactively as an administrator (I usually run as a standard user), and I was greeted with a dialog informing me about a “serious error” or the like. I chose to check for updates to the problem. What came back was more than I expected, but not really all that helpful for my particular situation.

Problem caused by ATI Graphics Driver

This problem was caused by ATI Graphics Driver.

This program was created by ATI Technologies, Inc.. ATI Technologies, Inc. does not currently have a solution for the problem that you reported.

Recommendation

——————

The following troubleshooting steps might prevent the problem from recurring.

Download and install an updated version of ATI Graphics Driver from one of the following locations:
Microsoft Update
ATI Technologies, Inc.

If an updated driver is not available for ATI Graphics Driver, check with your computer manufacturer.

If you are running the latest version of ATI Graphics Driver, contact ATI Technologies, Inc. for your support options.

Additional information

If this problem continues to occur after installing the latest product updates, we recommend you get assistance and troubleshooting information directly from ATI Technologies, Inc..

——————

I am running the latest driver, and ATI has discontinued the Radeon 9600 Pro. Not a big deal, as the problem has only happened twice. Of course, I would rather that it not happen at all…

»

Ran across this rather unique notion the other day. It works!

eb poi(@$peb+0×8)+0×36fa c6 00 8a

My interpretation is that this “enters byte values” “c6 00 8a” into the address starting at offset 0×36fa from the value pointed to by offset 8 into the PEB. Whatever that ultimately does!

»

Recently, after resuming my Vista laptop from hibernation, I was greeted with a rather strange wait, followed by a blue screen of death. Analysis of the dump yielded the following:

THREAD_STUCK_IN_DEVICE_DRIVER (ea)
The device driver is spinning in an infinite loop, most likely waiting for hardware to become idle. This usually indicates problem with the hardware itself or with the device driver programming the hardware incorrectly.
If the kernel debugger is connected and running when watchdog detects a timeout condition then DbgBreakPoint() will be called instead of KeBugCheckEx()and detailed message including bugcheck arguments will be printed to the
debugger. This way we can identify an offending thread, set breakpoints in it, and hit go to return to the spinning code to debug it further. Because KeBugCheckEx() is not called the .bugcheck directive will not return bugcheck
information in this case. The arguments are already printed out to the kernel debugger. You can also retrieve them from a global variable via
“dd watchdog!g_WdBugCheckData l5″ (use dq on NT64).
On MP machines (OS builds <= 3790) it is possible to hit a timeout when the spinning thread is interrupted by hardware interrupt and ISR or DPC routine is running at the time of the bugcheck (this is because the timeout’s work item can be delivered and handled on the second CPU and the same time). If this is the case you will have to look deeper at the offending thread’s stack (e.g. using dds) to determine spinning code which caused the timeout to occur.
Arguments:
Arg1: 870246b8, Pointer to a stuck thread object. Do .thread then kb on it to find the hung location.
Arg2: 00000000, Pointer to a DEFERRED_WATCHDOG object.
Arg3: 00000000, Pointer to offending driver name.
Arg4: 00000000, Number of times this error occurred. If a debugger is attached, this error is not always fatal — see DESCRIPTION below. On the blue screen, this will always equal 1.

Debugging Details:
——————

PEB is paged out (Peb.Ldr = 7ffd800c). Type “.hh dbgerr001″ for details

PEB is paged out (Peb.Ldr = 7ffd800c). Type “.hh dbgerr001″ for details

FAULTING_THREAD: 870246b8

DEFAULT_BUCKET_ID: GRAPHICS_DRIVER_FAULT

BUGCHECK_STR: 0xEA

PROCESS_NAME: Ati2evxx.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 89c2a825 to 81cace97

STACK_TEXT:
a53d7704 89c2a825 000000ea 870246b8 00000000 nt!KeBugCheckEx+0×1e
a53d7748 89c22bfa a53d7794 00000000 89c1d786 dxgkrnl!TdrTimedOperationBugcheckOnTimeout+0×2b
a53d7770 8b5785dc a53d7794 00000000 00000000 dxgkrnl!TdrTimedOperationDelay+0xc9
WARNING: Stack unwind information not available. Following frames may be wrong.
a53d77c0 8b576468 8b670040 a53d785c ffffffff atikmdag+0×255dc
a53d77dc 8b66782c 861bd000 a53d77f8 00000014 atikmdag+0×23468
a53d7838 8b670101 86a58008 8b670040 a53d785c atikmdag+0×11482c
a53d7868 8b6cd9da 8685b0e8 00000000 00000001 atikmdag+0×11d101
a53d7888 8b59f159 88340000 00000000 00000001 atikmdag+0×17a9da
a53d78a8 8b59505c 86a58000 86a61974 00000000 atikmdag+0×4c159
a53d78dc 8b5973e3 00000000 86a611e0 00000001 atikmdag+0×4205c
a53d7904 8b5b3be0 00000001 00000001 00000001 atikmdag+0×443e3
a53d7960 8b5b80ab 86a58000 00000000 00000001 atikmdag+0×60be0
a53d7980 8b58e38d 86a58000 a53d799c a53d7ba0 atikmdag+0×650ab
a53d79b8 8b554e80 86a58000 a53d7ba0 00000030 atikmdag+0×3b38d
a53d79dc 8b55a7de a53d7ba0 00000030 a53d7bd4 atikmdag+0×1e80
a53d7a00 8b55af33 0011000e 00000030 a53d7bd4 atikmdag+0×77de
a53d7a24 8b56bdeb 00000030 a53d7ba0 00000000 atikmdag+0×7f33
a53d7a54 8b56bf8a 00000000 a53d7b1c a53d7ba0 atikmdag+0×18deb
a53d7a74 89c4a7b2 8640a648 a53d7ab4 000000b8 atikmdag+0×18f8a
a53d7a94 89c4a455 a53d7ab4 a5b4b811 0012e910 dxgkrnl!DXGADAPTER::DdiEscape+0×3b
a53d7d38 81c4607a 0012e910 0012e94c 77940f34 dxgkrnl!DxgkEscape+0×4af
a53d7d38 77940f34 0012e910 0012e94c 77940f34 nt!KiFastCallEntry+0×12a
0012e94c 00000000 00000000 00000000 00000000 0×77940f34

STACK_COMMAND: .thread 0xffffffff870246b8 ; kb

FOLLOWUP_IP:
dxgkrnl!TdrTimedOperationBugcheckOnTimeout+2b
89c2a825 cc int 3

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: dxgkrnl!TdrTimedOperationBugcheckOnTimeout+2b

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: dxgkrnl

IMAGE_NAME: dxgkrnl.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 46899fd6

FAILURE_BUCKET_ID: 0xEA_IMAGE_dxgkrnl.sys

BUCKET_ID: 0xEA_IMAGE_dxgkrnl.sys

Followup: MachineOwner

Seems that the hardware was messed up, as I had to force the laptop to power down twice during subsequent boots, in order for Vista to make it to the logon prompt.

»