“Sean Bullington” wrote in message news:xxxxx@windbg…
>
> Phil,
> I checked my setup, and the event filters on mine haven’t changed
> from the defaults (unless someone else snuck in here and changed them).
> I have done this with both the free and checked kernel from a UP machine
> to a UP machine, but I don’t have an SMP XP/.Net box setup, so I can’t
> try it out on there… are you trying this on an SMP box? Has anyone
> else on the list had any luck copying drivers over the debug connection
> to an SMP box?
Wow, thanks for looking through that huge pile of debug out for the few
lines that matter. That’s way above and beyond!
My setup is 1P on both ends.
>
> For the record, here’s a log of my boot with CTRL-ALT-D turned on:
>
> Shutdown occurred…unloading all symbol tables.
> Waiting to reconnect…
> Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE
> Kernel Debugger connection established. (Initial Breakpoint requested)
> Symbol search path is:
>
symsrvsymsrv.dll\jackson\wintools\symsrv;srv*\jackson\wintools\downloads
tore*http://msdl.microsoft.com/download/symbols
> Executable search path is:
> Windows XP Kernel Version 2600 MP (1 procs) Checked x86 compatible
> Built by: 2600.xpclient.010817-1148
> Kernel base = 0x80a02000 PsLoadedModuleList = 0x80ae4150
> System Uptime: not available
> Break instruction exception - code 80000003 (first chance)
> nt!RtlpBreakWithStatusInstruction:
> 80aabb54 cc int 3
> kd> .kdfiles d:\drvmap.ini
> KD file assocations loaded from ‘d:\drvmap.ini’
> kd> sxe ld:phmdisp.dll
I see you are setting a breakpoint on loading your module, instead of
breakpointing on loading ALL modules. I missed that one, I’ll try it. At
least it would eliminate sitting on the F5 key to get to the part that’s
interesting. Except that it doesn’t look like it actually broke in? Or did
it break later, after the end of the trace you pasted?
[snip]
> KD: Accessing ‘D:\Host\kernel\build\chk_w2k\i386\phmdisp.dll’
> (\SystemRoot\System32\phmdisp.dll)
> File size 128KKdFile request for ‘\SystemRoot\System32\phmdisp.dll’
As you might have noticed, if you do a search on “accessing” in the text of
my message, it’s not there. It’s not there in my command window, either.
[snip]
> At this point, it’s copying the driver (hence the “.” before the
> “WRITE:” debug message).
> I don’t get any break before the module loads (nor do I know how I can
> tell WinDBG to break in before it checks to see if the file is mapped or
> not).
Being the GUI oriented fellow I am, I just looked at the event filters,
found Load Module, and enabled that. Then it breaks on all mod loads.
Do you remember what happened on your setup if you gave it a bad path to the
file you were trying to replace? Does it just ignore it, or does it
complain at all? I’m wondering if the problem is that I haven’t given it
the right path, and it just silently fails, instead of complaining about it?
Phil
–
Philip D. Barila
Seagate Technology, LLC
(720) 684-1842
Phil,
When I give a bad path for the driver binary that will be copied
(third line in the “map” declaration), I see the following message:
KdFile request for ‘\SystemRoot\System32\phmdisp.dll’ returns C0000001
(and of course, C0000001 == STATUS_UNSUCCESSFUL)
However when I have the correct path for the driver binary that will be
copied, the following is spit out:
KdFile request for ‘\SystemRoot\System32\phmdisp.dll’ returns 00000000
Now, if I change the other line (the second line in the “map”
declaration) to either of the following:
??\C:\Windows\system32\phmdisp.dll
or
\Windows\system32\phmdisp.dll
then the debugger will give the following error for both cases:
KdFile request for ‘\SystemRoot\System32\phmdisp.dll’ returns C000000F
even though the path should be correct. The only way it will work to
where the file is copied correctly is the following:
---- snip ----
map
\Systemroot\system32\phmdisp.dll
D:\Host\kernel\build\chk_w2k\i386\phmdisp.dll
---- snip ----
where the “D:” line points to the correct path to the new binary, and
the “\Systemroot” line points to the correct path on the target where
the driver lies. I don’t know if this is due to what the SCM has the
driver path stored as or what, but for my config this is the only way
it works.
I find it really odd that the debugger correctly looks for and fails to
find the driver with the alternate forms of the second line in the
mapping. The error message “KdFile request for
‘\SystemRoot\System32\phmdisp.dll’ returns C000000F” has the correct
path for the driver I want to replace, and obviously the kernel debugger
entered the KdFile function to try and load the file. Why in the world
the debug output would have the correct string, yet the KdFile would
failed out with STATUS_NO_SUCH_FILE is beyond me… the debugger seems
to know that it needs to try and bring this file over, yet it can’t /
won’t. Weird.
However the moral of this long rant is that I am always seeing a
“KdFile” error message (when I have the CTRL-ALT-D verbose debugging
on), whereas you are not (in your original post that also had the
verbose debugging on).
I did notice one other thing about your post that may or may not be
relevant… You are running the Free Build of an MP kernel on a UP
machine… is this on purpose? I know the checked builds were always MP,
but I don’t know if having the free build of the MP kernel on a UP
machine might be getting in the way or not…
From your post:
> Loading symbols for 804d0000 ntkrnlmp.exe -> ntkrnlmp.exe
> ModLoad: 804d0000 806aa000 ntkrnlmp.exe
> Windows XP Kernel Version 2600 MP (1 procs) Free x86 compatible
> Built by: 2600.xpclnt_qfe.010827-1803
> Kernel base = 0x804d0000 PsLoadedModuleList = 0x805450a8
> System Uptime: not available
And one other thing I’ll mention that I really doubt has any relevance
here, but is worth mentioning: .kdfiles cannot replace all drivers.
I’m not sure where the line is drawn or if there are only a specific few.
For instance, I was trying to replace win32k.sys with the checked build
(don’t ask 
over the debug connection, and could not. I emailed the
list about it, and got a response from Andre saying that the system
loads the win32k.sys in a different manner, and WinDBG would not be able
to intercept the loading… (look in the WinDBG mail logs on 4/12/2002)
However it would really suck if this was the case for storage filter
drivers, and I would guess they would have said something about it by now…
sean
Also,
I see you are setting a breakpoint on loading your module, instead of
breakpointing on loading *ALL* modules. I missed that one, I’ll try it. At
least it would eliminate sitting on the F5 key to get to the part that’s
interesting. Except that it doesn’t look like it actually broke in? Or did
it break later, after the end of the trace you pasted?
Yeh, it will break in after the binary is finished being copied over
the debug connection.
Hope some of this helps :\
sean
“Sean Bullington” wrote in message news:xxxxx@windbg…
>
> Phil,
> When I give a bad path for the driver binary that will be copied
> (third line in the “map” declaration), I see the following message:
>
> KdFile request for ‘\SystemRoot\System32\phmdisp.dll’ returns C0000001
>
> (and of course, C0000001 == STATUS_UNSUCCESSFUL)
> However when I have the correct path for the driver binary that will be
> copied, the following is spit out:
>
> KdFile request for ‘\SystemRoot\System32\phmdisp.dll’ returns 00000000
>
> Now, if I change the other line (the second line in the “map”
> declaration) to either of the following:
>
> ??\C:\Windows\system32\phmdisp.dll
> or
> \Windows\system32\phmdisp.dll
>
> then the debugger will give the following error for both cases:
> KdFile request for ‘\SystemRoot\System32\phmdisp.dll’ returns C000000F
>
> even though the path should be correct. The only way it will work to
> where the file is copied correctly is the following:
> ---- snip ----
> map
> \Systemroot\system32\phmdisp.dll
> D:\Host\kernel\build\chk_w2k\i386\phmdisp.dll
> ---- snip ----
Wow, Sean, this is really, really above and beyond the call of duty. Thanks
for testing that out for me!
You are right, I never see a message at all. That supports my conclusion
that the thing isn’t even trying to replace the driver. I asked windbgfb if
this facility was good for replacing boot drivers, and they haven’t
responded one way or another. Win32k.sys is one of the last drivers to
load, so if it only replaces drivers later than that, it’s not much use.
Funny, the windbg help specifically mentions replacing win32k.sys with this
facility. Yes, I searched the archive, found your query and Andre’s
response, before I ever wrote these tomes. Something seems to be broken
here in my setup, but I’m completely swoggled to say what it is.
Yes, I noticed the MP kernel, that’s what installed on the box. Perhaps
this dumb Dell of mine, with unusable PCI slots and a PS that just refuses
to have anything plugged into it while it’s on, is reporting itself as an MP
box. Or maybe it’s an update that did that, since
C:\windows\repair\setup.log says it installed ntoskrnl.ex_ as ntoskrnl.exe,
and halaacpi.dl_ as hal.dll. Now it’s loading ntkrnlmp as ntoskrnl, and
halmacpi.dll, and I’m not sure why.
[snip]
Thank you for digging so deeply into this for me, and for confirming that
the breakpoint on the modload isn’t really much use for debugging, since it
doesn’t break until after it has tried/not tried to load the mapped file.
David, Andre, any further comments/suggestions/incantations?
Phil
–
Philip D. Barila
Seagate Technology, LLC
(720) 684-1842
>
I asked windbgfb if this facility was good for replacing boot drivers, and they haven’t responded one way or another.
I’d be interested to hear what they have to say (especially if the
answer is “no”).
Thank you for digging so deeply into this for me, and for confirming that
the breakpoint on the modload isn’t really much use for debugging, since it
doesn’t break until after it has tried/not tried to load the mapped file.
No problem at all. Other people on this list have gone way above and
beyond for me, I only wish I could have said “hey, here’s a simple way
to fix it.” :\
And besides, hopefully we’ll figure out what’s wrong and someone later
on will find these posts in the archive and it will help them as well.
Also for the MS guys following this thread, it may be helpful to update
the docs with some troubleshooting information such as:
- using CTRL-ALT-D then searching for the KdFile() references to see
what the target system is trying or not trying to replace over the
debugger connection, and the associated error codes (though they’re
pretty self-explanatory) - the fact that certain drivers, and more specifically *which* drivers,
cannot be loaded over a debug connection (such as win32k.sys)
Or like I mentioned in an earlier email, something like a ‘.kdfiles
noisy’ to turn on debugging info for ‘.kdfiles’… the current
implementation doesn’t really give any info or error feedback to the
users other than if the map file could or couldn’t be loaded; nothing as
to why the file couldn’t be loaded, why a driver wasn’t copied, etc.
This feature rocks and I’m pretty sure it’ll come in handy for most
people who write kernel-mode code to run on XP and beyond…
Just a wish, not a demand
sean
I am dreaming of…:
Wouldn’t it be great if there was a GUI listing all currently running
modules on the target and then select the replacement modules on the
local host ? This info should be stored in the workspace to be
available for the next boot.
| Norbert Kawulski | mailto:xxxxx@stollmann.de |
“When love and skill work together, expect a masterpiece. - John
Ruskin”