Magic incantation to make .kdfiles *do* something?

WINDBG
1

I’ve started a boot storage filter driver project, I’ve got the filter
loading, it didn’t crash the machine, so everybody is happy. Then I put a
*very* dumb mistake into the source, compiled, copied the binary, restarted,
boom!

OK, so I can use the handy-dandy file replacement map, since I’m running
Windows XP on both ends, and have this really cool 1394 connection between
my host and target and, besides WinDBG 6.0.17.0 help says I can, right?

So I make a mapfile on my host system,
D:\Projects\Drivers\DriverReplacement.Map. The contents of same are:
map
\Systemroot\system32\drivers\SeUlator.sys
D:\Projects\Drivers\SeUlator\objchk\i386\SeUlator.sys
I’ve also tried:
??\C:\Windows\system32\drivers\SeUlator.sys
C:\Windows\system32\drivers\SeUlator.sys
\Windows\system32\drivers\SeUlator.sys

The last one because that is the path to ntoskrnl.exe visible in the memory
above ebp when the system breaks on “First symbol load”. (I don’t assert
that it’s actually on the stack at that point, because I don’t know what’s
really in ebp at that point, though being on the stack is a reasonable
assumption.)

In the WinDBG command window, I type:
.kdfiles D:\Projects\Drivers\DriverReplacement.Map
and I get:
KD file assocations loaded from ‘D:\Projects\Drivers\DriverReplacement.Map’

I cleared and reloaded them each time I changed the target path.

Anyway, I can see no evidence of any attempt at file replacement happening.
Even using Ctl+Alt+D, I don’t ever see anything like this, copied from Sean
Bullington’s query last week:

KD: Accessing
‘D:\funk\proxy4\Host\kernel\build\chk_w2k\i386\phmdisp.dll’
(\SystemRoot\System32\phmdisp.dll)
File size 128K…

What I see, with Verbose mode ON, and !sym noisy “Nooisy mode on”, without
the Ctl+Alt+D spew, is:
ModLoad: f9767000 f9768b80 SeUlator.sys
Loading symbols for f9767000 SeUlator.sys -> SYMSRV:
http://msdl.microsoft.com/download/symbols/SeUlator.pdb/30F04D980D264ED5B9D6
B28048F903F71/SeUlator.pdb not found
SYMSRV:
http://msdl.microsoft.com/download/symbols/SeUlator.pdb/30F04D980D264ED5B9D6
B28048F903F71/SeUlator.pd_ not found
SYMSRV:
c:\windows\symbols\SeUlator.pdb\30F04D980D264ED5B9D6B28048F903F71\SeUlator.p
db - file not found
DBGHELP: d:\projects\drivers\SeUlator.pdb - file not found
DBGHELP: d:\projects\drivers\symbols\sys\SeUlator.pdb - file not found
DBGHELP: d:\projects\drivers\sys\SeUlator.pdb - file not found
DBGHELP: D:\Projects\Drivers\SeUlator\objchk\i386\SeUlator.pdb - mismatched
pdb
DBGHELP: Couldn’t load mismatched pdb for SeUlator.sys - Type “.hh
dbgerr003” for details
SeUlator.sys
*** ERROR: Module load completed but symbols could not be loaded for
SeUlator.sys
DBGHELP: SeUlator - no symbols loaded

So it appears that it’s not even trying to replace the old file with the new
one. I’ve tried this with both 1394 and null-modem cable connections, with
indistinguishable results. Have I missed something obvious?

Thanks,

Phil

Philip D. Barila
Seagate Technology, LLC
(720) 684-1842

2

Hrm everything looks OK in your setup… My file is simply called
drvmap.ini, and looks like:

map
\Systemroot\system32\drivers\phmmini.sys
D:\Host\kernel\build\chk_w2k\i386\phmmini.sys

And my loading looks the exact same as yours:
kd> .kdfiles d:\drvmap.ini
KD file assocations loaded from ‘d:\drvmap.ini’

The only difference seems to be that I’m using a serial connection,
although I’ve used the same method over 1394.
One error I’ve stumbled over is, if the pdb is in use by WinDBG, and you
build, you’ll get the lovely error about not being able to create the
pdb cause it is locked. And thus the final binary is not created. When
the target machine reboots, the driver won’t be copied over the
connection because the binary isn’t there (and there is no warning, etc.
shown in WinDBG).

sean

Phil Barila wrote:

I’ve started a boot storage filter driver project, I’ve got the filter
loading, it didn’t crash the machine, so everybody is happy. Then I put a
*very* dumb mistake into the source, compiled, copied the binary, restarted,
boom!

OK, so I can use the handy-dandy file replacement map, since I’m running
Windows XP on both ends, and have this really cool 1394 connection between
my host and target and, besides WinDBG 6.0.17.0 help says I can, right?

So I make a mapfile on my host system,
D:\Projects\Drivers\DriverReplacement.Map. The contents of same are:
map
\Systemroot\system32\drivers\SeUlator.sys
D:\Projects\Drivers\SeUlator\objchk\i386\SeUlator.sys
I’ve also tried:
??\C:\Windows\system32\drivers\SeUlator.sys
C:\Windows\system32\drivers\SeUlator.sys
\Windows\system32\drivers\SeUlator.sys

The last one because that is the path to ntoskrnl.exe visible in the memory
above ebp when the system breaks on “First symbol load”. (I don’t assert
that it’s actually on the stack at that point, because I don’t know what’s
really in ebp at that point, though being on the stack is a reasonable
assumption.)

In the WinDBG command window, I type:
.kdfiles D:\Projects\Drivers\DriverReplacement.Map
and I get:
KD file assocations loaded from ‘D:\Projects\Drivers\DriverReplacement.Map’

I cleared and reloaded them each time I changed the target path.

Anyway, I can see no evidence of any attempt at file replacement happening.
Even using Ctl+Alt+D, I don’t ever see anything like this, copied from Sean
Bullington’s query last week:

KD: Accessing
‘D:\funk\proxy4\Host\kernel\build\chk_w2k\i386\phmdisp.dll’
(\SystemRoot\System32\phmdisp.dll)
File size 128K…

What I see, with Verbose mode ON, and !sym noisy “Nooisy mode on”, without
the Ctl+Alt+D spew, is:
ModLoad: f9767000 f9768b80 SeUlator.sys
Loading symbols for f9767000 SeUlator.sys -> SYMSRV:
http://msdl.microsoft.com/download/symbols/SeUlator.pdb/30F04D980D264ED5B9D6
B28048F903F71/SeUlator.pdb not found
SYMSRV:
http://msdl.microsoft.com/download/symbols/SeUlator.pdb/30F04D980D264ED5B9D6
B28048F903F71/SeUlator.pd_ not found
SYMSRV:
c:\windows\symbols\SeUlator.pdb\30F04D980D264ED5B9D6B28048F903F71\SeUlator.p
db - file not found
DBGHELP: d:\projects\drivers\SeUlator.pdb - file not found
DBGHELP: d:\projects\drivers\symbols\sys\SeUlator.pdb - file not found
DBGHELP: d:\projects\drivers\sys\SeUlator.pdb - file not found
DBGHELP: D:\Projects\Drivers\SeUlator\objchk\i386\SeUlator.pdb - mismatched
pdb
DBGHELP: Couldn’t load mismatched pdb for SeUlator.sys - Type “.hh
dbgerr003” for details
SeUlator.sys
*** ERROR: Module load completed but symbols could not be loaded for
SeUlator.sys
DBGHELP: SeUlator - no symbols loaded

So it appears that it’s not even trying to replace the old file with the new
one. I’ve tried this with both 1394 and null-modem cable connections, with
indistinguishable results. Have I missed something obvious?

Thanks,

Phil

Philip D. Barila
Seagate Technology, LLC
(720) 684-1842

You are currently subscribed to windbg as: xxxxx@stg.com
To unsubscribe send a blank email to %%email.unsub%%

3

“Sean Bullington” wrote in message news:xxxxx@windbg…
>
> Hrm everything looks OK in your setup… My file is simply called
> drvmap.ini, and looks like:
>
> map
> \Systemroot\system32\drivers\phmmini.sys
> D:\Host\kernel\build\chk_w2k\i386\phmmini.sys
>
> And my loading looks the exact same as yours:
> kd> .kdfiles d:\drvmap.ini
> KD file assocations loaded from ‘d:\drvmap.ini’
>
> The only difference seems to be that I’m using a serial connection,
> although I’ve used the same method over 1394.
> One error I’ve stumbled over is, if the pdb is in use by WinDBG, and you
> build, you’ll get the lovely error about not being able to create the
> pdb cause it is locked. And thus the final binary is not created. When
> the target machine reboots, the driver won’t be copied over the
> connection because the binary isn’t there (and there is no warning, etc.
> shown in WinDBG).

Sean,

Thanks for checking. I tried both serial and 1394, and couldn’t tell the
difference, except for speed. And I know I got a good build, because my
build environment sure complains when the pdb is in use, and besides, the
reason for the PDB mismatch was that I had a driver without the bug waiting
to be tranferred to the target, with a matching PDB, which no longer matched
the driver on the host. It was trying to load the PDB because I tried to
set a breakpoint on SeUlator!DriverEntry, but it couldn’t load the PDB, so
it couldn’t instantiate the BP.

Solved with the repair console, but I’d really like to get this working,
because I’m sure I’m going to do it again…

Hmmph.

Phil
–
Philip D. Barila
Seagate Technology, LLC
(720) 684-1842

4

“Roger Coote” wrote in message news:xxxxx@windbg…
>
> Hi,
> I use .kdfiles ALL the time, some other people here have had some initial
> problems but I think we found the mapping file parser did not like an
empty
> line at the end of the file, I think the parser is not very robust.
Ensure
> there are not white spaces at the end of each line and that there are not
> blank lines at the end.

Just in case it had something to do with file location, I copied the map
file to D:\Foo\Map.ini, and copied the sys file to D:\Foo\Foolator.sys, with
the requisite change to the last line of the map file, making sure that the
end of that line is also the end of the file. Then I entered .kdfiles
D:\Foo\Map.ini, and it loaded the file associations from that file.

However, it did not load the driver from the new location, either, so it
appears to be non-functional on my system. Is there a WinDBG option or
boot.ini switch I’ve missed? I turned WFC completely off so I could load a
new disk class driver from the DDK source, is this feature dependent on WFC
being on?

More things to try, I guess.

Phil
–
Philip D. Barila
Seagate Technology, LLC
(720) 684-1842

5

What version of the debugger is this? I think at least some of these
issues should be fixed in 6.0.17.

There is documentation in the debugger.chm that describes some
information that may help you troubleshoot the problem. See the section
on “Mapping Driver Files” linked off the .kdfiles help.

-----Original Message-----
From: Phil Barila [mailto:xxxxx@Seagate.com]
Sent: Thursday, August 29, 2002 12:47 PM
To: Kernel Debugging Interest List
Subject: [windbg] Re: Magic incantation to make .kdfiles *do* something?

“Roger Coote” wrote in message
news:xxxxx@windbg…
>
> Hi,
> I use .kdfiles ALL the time, some other people here have had some
> initial problems but I think we found the mapping file parser did not
> like an
empty
> line at the end of the file, I think the parser is not very robust.
Ensure
> there are not white spaces at the end of each line and that there are
> not blank lines at the end.

Just in case it had something to do with file location, I copied the map
file to D:\Foo\Map.ini, and copied the sys file to D:\Foo\Foolator.sys,
with the requisite change to the last line of the map file, making sure
that the end of that line is also the end of the file. Then I entered
.kdfiles D:\Foo\Map.ini, and it loaded the file associations from that
file.

However, it did not load the driver from the new location, either, so it
appears to be non-functional on my system. Is there a WinDBG option or
boot.ini switch I’ve missed? I turned WFC completely off so I could
load a new disk class driver from the DDK source, is this feature
dependent on WFC being on?

More things to try, I guess.

Phil
–
Philip D. Barila
Seagate Technology, LLC
(720) 684-1842

—
You are currently subscribed to windbg as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%

6

“David Holcomb” wrote in message
news:xxxxx@windbg…
>
> What version of the debugger is this? I think at least some of these
> issues should be fixed in 6.0.17.
>
> There is documentation in the debugger.chm that describes some
> information that may help you troubleshoot the problem. See the section
> on “Mapping Driver Files” linked off the .kdfiles help.

Yep, it’s 6.0.17. Yep, it’s Windows XP at both ends. Yep, I’ve looked at
the .kdfiles and Mapping Driver Files pages in WinDBG help. Yep, I’ve tried
checked builed kernel, free build kernel, WFC disabled, WFC enabled, serial
port, 1394 port, !sym noisy, !sym quiet,Verbose mode ON, Verbose mode OFF,
map file deep in a directory tree, map file one directory down from the root
of a disk, replacement file deep in a tree, replacement file one directory
down from the root, replacement path prefixed with \Systemroot,
??\C:\windows, C:\windows, \windows, and even just
system32\drivers\SeUlator.sys, drivers\SeUlator.sys and SeUlator.sys with no
path at all, and even intentionally bad paths for the source and target.
Never has it indicated that it’s even attemtpting to replace the driver,
never complained that the path is bad or that it can’t find the replacement
file, or any hint at all that it’s even trying to work.

Andre or Nathan, anything I missed in all that? Are you sure there isn’t an
option that needs to be selected somewhere, or a boot.ini setting I’m still
missing?

Phil
–
Philip D. Barila
Seagate Technology, LLC
(720) 684-1842

7

Hi, all

I can see LPC message structure contaions a large number message ID(00000000
00110000 00000000 00000001)?
What does it mean?

the following context is sit in TermSrv.exe.

THREAD 84d97020 Cid a9.153 Teb: 7ff8d000 Win32Thread: 00000000 WAIT:
(WrLpcReceive) UserMode Non-Alertable
80c9fd28 Semaphore Limit 0x7fffffff
Not impersonating
Owning Process 80c9f6a0
WaitTime (seconds) 4293434
Context Switch Count 1178
UserTime 0:00:00.0015
KernelTime 0:00:00.0046
Start Address KERNEL32!BaseThreadStartThunk (0x77ed5370)
Stack Init ad24c000 Current ad24be28 Base ad24c000 Limit ad249000
Call 0
Priority 11 BasePriority 10 PriorityDecrement 0 DecrementCount 0
Kernel stack not resident.

ChildEBP RetAddr Args to Child
ad24be40 80118f9e 00545da1 00000000 0013ada8 nt!KiSwapThread+0x1b1
ad24be64 801855ea 80c9fd28 00000010 24be8001
nt!KeWaitForSingleObject+0x1e2
ad24beec 80148679 000000ac 1ee5ff6c 0013ad90
nt!NtReplyWaitReceivePort+0x322
ad24beec 77f5833f 000000ac 1ee5ff6c 0013ad90 nt!KiSystemService+0xc9
1ee5fdec 77def287 000000ac 1ee5ff6c 0013ad90
ntdll!ZwReplyWaitReceivePort+0xb
1ee5ff90 77defcea 77dec0f6 0013df70 1ee5ffec
RPCRT4!WMSG_ADDRESS::ReceiveLotsaCalls+0x5b
1ee5ff94 77dec0f6 0013df70 1ee5ffec 0016da68
RPCRT4!RecvLotsaCallsWrapper+0x9
1ee5ffac 77dec04b 001621d0 77f54f63 77ed4f65
RPCRT4!BaseCachedThreadRoutine+0x91
1ee5ffb8 77ed4f65 0016cb80 0016da68 77f54f63
RPCRT4!ThreadStartRoutine+0x17
1ee5ffec 00000000 77dec034 0016cb80 00000000
KERNEL32!BaseThreadStart+0x51

0: kd> dc 0013ad90
0013ad90 00500038 00300001 000000d9 000000d8 8.P…0…
0013ada0 00545da1 00000000 77de4008 0012ea20 .]T…@.w …
0013adb0 0014d370 721a7b38 0014d370 0012ea59 p…8{.rp…Y…
0013adc0 00000001 0014d840 000004f8 000004f8 …@…
0013add0 00000000 00000000 00000000 77de170e …w
0013ade0 00000001 00133c20 00000000 0012f3ec … <…
0013adf0 007b0000 0012f4b8 77f83b64 77f8e838 …{…d;.w8…w
0013ae00 ffffffff 0012f438 77f54e4e 00130650 …8…NN.wP…

0: kd> .load ctxjpn.dll
0: kd> !lpcmsg 0013ad90
MajorVer:0xf
MinorVer:0x565
ActualMessageLength : 56
TotalMessageLength : 80
MessageType : 3145729
ClientProcessId : 0xd9
ClientThreadId : 0xd8
MessageId : 0x545da1
SharedSectionSize : 0
BeginMsgAdr : 0x13ada8
EndMsgAdr : 0x13aea8

0: kd> .formats 00300001
Evaluate expression:
Hex: 00300001
Decimal: 3145729
Octal: 00014000001
Binary: 00000000 00110000 00000000 00000001
Chars: .0…
Time: Fri Feb 06 18:48:49 1970
Float: low 4.40811e-039 high 0
Double: 1.5542e-317

0: kd> !process d9 7
Searching for Process with Cid == d9
PROCESS 80c407c0 Cid: 00d9 Peb: 7ffdf000 ParentCid: 00ce
DirBase: 0a1d6000 ObjectTable: 80c62da8 TableSize: 94.
Image: dm_ep_engine.ex
VadRoot 80c40628 Clone 0 Private 455. Modified 6626. Locked 0.
80C4097C MutantState Signalled OwningThread 0
Token e1cc5ab0
ElapsedTime 18:37:52.0206
UserTime 0:00:25.0062
KernelTime 0:00:47.0859
QuotaPoolUsage[PagedPool] 12954
QuotaPoolUsage[NonPagedPool] 85496
Working Set Sizes (now,min,max) (947, 50, 345) (3788KB, 200KB, 1380KB)
PeakWorkingSetSize 1096
VirtualSize 22 Mb
PeakVirtualSize 24 Mb
PageFaultCount 303579
MemoryPriority FOREGROUND
BasePriority 9
CommitCharge 480

THREAD 80c60020 Cid d9.d8 Teb: 7ffde000 Win32Thread: e1cc55c8
WAIT: (UserRequest) UserMode Alertable
80c360c0 NotificationEvent
80c60108 NotificationTimer
IRP List:
8507cee8: (0006,0100) Flags: 00000070 Mdl: 00000000
Not impersonating
Owning Process 80c407c0
WaitTime (seconds) 4295320
Context Switch Count 694581 LargeStack
UserTime 0:00:24.0828
KernelTime 0:00:47.0250
Start Address KERNEL32!BaseProcessStartThunk (0x77ed537c)
Win32 Start Address 0x004180e0
Stack Init bf728000 Current bf727e64 Base bf728000 Limit bf725000
Call 0
Priority 13 BasePriority 9 PriorityDecrement 0 DecrementCount 0

ChildEBP RetAddr Args to Child
bf727e7c 80118f9e 00000000 bf727ec8 8019c601 nt!KiSwapThread+0x1b1
bf727ea0 8019c765 80c360c0 00000006 8019c601
nt!KeWaitForSingleObject+0x1e2
bf727ef0 80148679 00000018 00000001 bf727ec8
nt!NtWaitForSingleObject+0xa9
bf727ef0 77f58673 00000018 00000001 bf727ec8 nt!KiSystemService+0xc9
0012f7f0 77ee96ee 00cf0000 00000000 00008000
ntdll!ZwWaitForSingleObject+0xb
0012f800 77ee9a17 0012f818 80000002 00000001
KERNEL32!FreeVirtualBuffer+0x12
0012f87c 77ee95c6 00000000 0000001b 00000001
KERNEL32!BaseDllFormatMessage+0x2ef
0012f8a4 77f12f20 77f15a68 ffffffff 0012fae8
KERNEL32!FormatMessageW+0x20
0012fb70 77f83b64 77f8e0f8 ffffffff 0012feac
KERNEL32!_except_handler3
0012ff0c 00000000 0012fee0 00000004 0012ff60 ntdll!_except_handler3

THREAD 80c0f420 Cid d9.14c Teb: 7ffdd000 Win32Thread: 00000000
WAIT: (WrLpcReply) UserMode Non-Alertable
80c0f608 Semaphore Limit 0x1
Waiting for reply to LPC MessageId 005413f7:
Not impersonating
Owning Process 80c407c0
WaitTime (seconds) 4280335
Context Switch Count 2248
UserTime 0:00:00.0031
KernelTime 0:00:00.0015
Start Address KERNEL32!BaseThreadStartThunk (0x77ed5370)
Win32 Start Address ADVAPI32!SmMonitorThread (0x77daba02)
Stack Init bf5dc000 Current bf5dbe30 Base bf5dc000 Limit bf5d9000
Call 0
Priority 12 BasePriority 9 PriorityDecrement 0 DecrementCount 0
Kernel stack not resident.

ChildEBP RetAddr Args to Child
bf5dbe48 80118f9e 80c0f61c 80c0f5d8 00000000 nt!KiSwapThread+0x1b1
bf5dbe6c 8018328d 80c0f608 00000011 5dbe8801
nt!KeWaitForSingleObject+0x1e2
bf5dbef0 80148679 0000011c 00149228 00149228
nt!NtRequestWaitReplyPort+0x539
bf5dbef0 77f5836f 0000011c 00149228 00149228 nt!KiSystemService+0xc9
0119fc90 00000000 00000000 00000000 00000000
ntdll!ZwRequestWaitReplyPort+0xb

Thanks,
Futoshi