.kdfiles and silent failure

WINDBG
1

I just wasted about an hour chasing down a problem with KD, and I wanted to
advise the list of an obscure problem with using .kdfiles.

If a problem occurs when KD + target kernel tries to copy a driver binary
over the debugger cable, then you receive no warning at all that the copy
failed, and in the debug console, everything appears to work fine. However,
the driver binary is *not* copied over, and of course 1) your changes to the
driver are ignored because the old binary is loaded, and 2) symbols do not
match. But since the debug console appears to show KD copying the file
over, you tend to assume it *worked*.

This happened to me because a driver binary on the target machine was marked
read-only, because SetupDi* copied the file from a read-only file. Without
any leads from KD, I wasted a lot of time trying to fix a “symbol mismatch”
problem when the root problem wasn’t a symbol mismatch at all.

Microsoft: Please fix this. Error diagnostics are very important,
especially when debugging such finnicky beasts as device drivers. No error
output at all is unacceptable in a situation like this.

Developers: If you get stuck in a situation where you “build -c” your
drivers, but you get symbol mismatches, inconsistent behavior, etc. then
verify that the binary really was copied over, by checking the file on the
target machine. Make sure the security descriptor allows writing, and that
the file is not marked read-only.

– arlie

2

This requires a kernel change on the target side so it isn’t something
that can be fixed in the debugger. We have already made such a kernel
change for Windows Vista, and I believe it might have gone into Windows
Server 2003 SP1. What OS was the target running?

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Arlie Davis
Sent: Tuesday, October 18, 2005 11:22 AM
To: Kernel Debugging Interest List
Subject: [windbg] .kdfiles and silent failure

I just wasted about an hour chasing down a problem with KD, and I wanted
to advise the list of an obscure problem with using .kdfiles.

If a problem occurs when KD + target kernel tries to copy a driver
binary over the debugger cable, then you receive no warning at all that
the copy failed, and in the debug console, everything appears to work
fine. However, the driver binary is *not* copied over, and of course 1)
your changes to the driver are ignored because the old binary is loaded,
and 2) symbols do not match. But since the debug console appears to
show KD copying the file over, you tend to assume it *worked*.

This happened to me because a driver binary on the target machine was
marked read-only, because SetupDi* copied the file from a read-only
file. Without any leads from KD, I wasted a lot of time trying to fix a
“symbol mismatch” problem when the root problem wasn’t a symbol mismatch
at all.

Microsoft: Please fix this. Error diagnostics are very important,
especially when debugging such finnicky beasts as device drivers. No
error output at all is unacceptable in a situation like this.

Developers: If you get stuck in a situation where you “build -c” your
drivers, but you get symbol mismatches, inconsistent behavior, etc. then
verify that the binary really was copied over, by checking the file on
the target machine. Make sure the security descriptor allows writing,
and that the file is not marked read-only.

– arlie

You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

On similar lines, the kdfiles copy is not atomic.
“Arlie Davis” wrote in message news:xxxxx@windbg…
I just wasted about an hour chasing down a problem with KD, and I wanted to advise the list of an obscure problem with using .kdfiles.

If a problem occurs when KD + target kernel tries to copy a driver binary over the debugger cable, then you receive no warning at all that the copy failed, and in the debug console, everything appears to work fine. However, the driver binary is not copied over, and of course 1) your changes to the driver are ignored because the old binary is loaded, and 2) symbols do not match. But since the debug console appears to show KD copying the file over, you tend to assume it worked.

This happened to me because a driver binary on the target machine was marked read-only, because SetupDi* copied the file from a read-only file. Without any leads from KD, I wasted a lot of time trying to fix a “symbol mismatch” problem when the root problem wasn’t a symbol mismatch at all.

Microsoft: Please fix this. Error diagnostics are very important, especially when debugging such finnicky beasts as device drivers. No error output at all is unacceptable in a situation like this.

Developers: If you get stuck in a situation where you “build -c” your drivers, but you get symbol mismatches, inconsistent behavior, etc. then verify that the binary really was copied over, by checking the file on the target machine. Make sure the security descriptor allows writing, and that the file is not marked read-only.

– arlie