ndiskd on WXP.SP1 - what more do i need to make this work again?

when i try to use the ndiskd extensions on the checked build of xp sp1, i
get the error below. this works fine pre SP1 (checked). the symbols are
freshly downloaded from the MSFT symbol server at
http://msdl.microsoft.com/download/symbols so if they are not good enough i
sure don’t know where to get any better ones.

any help would be appreciated. i really don’t feel like going back to
wandering through ndis datastructures by hand…

thanks,
-dave cattley

kd> !ndiskd.protocols
Protocol ffa55b30:
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** ***
*************************************************************************
Cant get offset of Name in Protocol block!
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** ***
*************************************************************************

The message only shows up if you really are missing a necessary symbol
file. How exactly are you downloading the symbols from the symbol
server? Do you have the symbol server in your sympath? Are you
debugging a live kernel session or a dump?

Do a ‘lml’ and then do a ‘!sym noisy’ and a ‘.reload /f .’.
That output will tell exactly which symbol file(s) the debugger is
looking for and we can find out if the file is supposed to be on the
Internet public smbol server. If you want to start from scratch either
stop and restart your debugger or do a ‘.reload’ and then retry your
commands.

-----Original Message-----
From: David R. Cattley [mailto:xxxxx@msn.com]
Sent: Friday, October 18, 2002 7:11 AM
To: Kernel Debugging Interest List
Subject: [windbg] ndiskd on WXP.SP1 - what more do i need to make this
work again?

when i try to use the ndiskd extensions on the checked build of xp sp1,
i get the error below. this works fine pre SP1 (checked). the symbols
are freshly downloaded from the MSFT symbol server at
http://msdl.microsoft.com/download/symbols so if they are not good
enough i sure don’t know where to get any better ones.

any help would be appreciated. i really don’t feel like going back to
wandering through ndis datastructures by hand…

thanks,
-dave cattley

kd> !ndiskd.protocols
Protocol ffa55b30:




Your debugger is not using the correct symbols

In order for this command to work properly, your symbol path
must point to .pdb files that have full type information.

Certain .pdb files (such as the public OS symbols) do not
contain the required information. Contact the group that
provided you with these symbols if you need this command to
work.


*

Cant get offset of Name in Protocol block!




Your debugger is not using the correct symbols

In order for this command to work properly, your symbol path
must point to .pdb files that have full type information.

Certain .pdb files (such as the public OS symbols) do not
contain the required information. Contact the group that
provided you with these symbols if you need this command to
work.








Your debugger is not using the correct symbols

In order for this command to work properly, your symbol path
must point to .pdb files that have full type information.

Certain .pdb files (such as the public OS symbols) do not
contain the required information. Contact the group that
provided you with these symbols if you need this command to
work.



*


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

The message can also appear if the PDB is loaded but the symbol being
looked for doesn’t exist in the PDB.

Sometimes the PDB on the symbol server can be updated, but (as far as I
know) there is no logic to detect an update and pull it down to your
downlevel store. If there is an update then you need to manually delete
the PDB from your downlevel store. Then the next time you need the PDB
the debugger will go fetch it again from the symbol server.

To know what file to delete you can use noisy symbol loading like David
mentioned. You could also just delete your whole downlevel store (my
choice). The bad part about that is that the debugger will have to
re-d/l all needed PDBs. If you have a fast connection that may not be a
problem.

I don’t know if an old PDB version is your problem, but personally that
is what I would check right after verifing that PDBs are being loaded.

-----Original Message-----
From: David Holcomb
Sent: Friday, October 18, 2002 8:33 AM
To: Kernel Debugging Interest List
Subject: [windbg] RE: ndiskd on WXP.SP1 - what more do i need to make
this work again?

The message only shows up if you really are missing a necessary symbol
file. How exactly are you downloading the symbols from the symbol
server? Do you have the symbol server in your sympath? Are you
debugging a live kernel session or a dump?

Do a ‘lml’ and then do a ‘!sym noisy’ and a ‘.reload /f .’.
That output will tell exactly which symbol file(s) the debugger is
looking for and we can find out if the file is supposed to be on the
Internet public smbol server. If you want to start from scratch either
stop and restart your debugger or do a ‘.reload’ and then retry your
commands.

-----Original Message-----
From: David R. Cattley [mailto:xxxxx@msn.com]
Sent: Friday, October 18, 2002 7:11 AM
To: Kernel Debugging Interest List
Subject: [windbg] ndiskd on WXP.SP1 - what more do i need to make this
work again?

when i try to use the ndiskd extensions on the checked build of xp sp1,
i get the error below. this works fine pre SP1 (checked). the symbols
are freshly downloaded from the MSFT symbol server at
http://msdl.microsoft.com/download/symbols so if they are not good
enough i sure don’t know where to get any better ones.

any help would be appreciated. i really don’t feel like going back to
wandering through ndis datastructures by hand…

thanks,
-dave cattley

kd> !ndiskd.protocols
Protocol ffa55b30:




Your debugger is not using the correct symbols

In order for this command to work properly, your symbol path
must point to .pdb files that have full type information.

Certain .pdb files (such as the public OS symbols) do not
contain the required information. Contact the group that
provided you with these symbols if you need this command to
work.


*

Cant get offset of Name in Protocol block!




Your debugger is not using the correct symbols

In order for this command to work properly, your symbol path
must point to .pdb files that have full type information.

Certain .pdb files (such as the public OS symbols) do not
contain the required information. Contact the group that
provided you with these symbols if you need this command to
work.








Your debugger is not using the correct symbols

In order for this command to work properly, your symbol path
must point to .pdb files that have full type information.

Certain .pdb files (such as the public OS symbols) do not
contain the required information. Contact the group that
provided you with these symbols if you need this command to
work.



*


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


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

David & Nathan,

Thanks for the suggestions. I had actually done Nathans suggestion prior -
kill my entire symbol cache and let Windbg get new files from the public
server. That had not solved the problem and I’m sorry I didn’t mention that
in my first post.

As to David’s question about how I get symbols: I have my _NT_SYMBOL_PATH
environment variable set to the string

SRV*\beetlecat\symbols*http://msdl.microsoft.com/download/symbols

Plain and simple. The share \beetlecat\symbols is actually on the same
machine. All that seems to work because after killing the entire cache, it
filled up again!

So here is what Windbg emitted in response to David’s suggestion…

kd> lml
start end module name
80a02000 80d6d000 nt (pdb symbols)
\beetlecat\symbols\ntoskrnl.pdb\E63229074EAC4B99BE3A727348280AA91\ntoskrnl.
pdb
f9bba000 f9c1ed00 NDIS (pdb symbols)
\beetlecat\symbols\ndis.pdb\1E0AE56CDDCF452B937C5A6CA422BDA51\ndis.pdb

kd> !sym noisy
noisy mode - symbol prompts on
kd> .reload /f ndis.sys
DBGHELP:
\beetlecat\symbols\ndis.pdb\1E0AE56CDDCF452B937C5A6CA422BDA51\ndis.pdb - OK
DBGHELP: NDIS - public symbols -
\beetlecat\symbols\ndis.pdb\1E0AE56CDDCF452B937C5A6CA422BDA51\ndis.pdb

The !ndiskd.protocols command still fails with the string of messages
indicating that type information is missing:

kd> !ndiskd.protocols
Protocol ffadd6d0:
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** ***
*************************************************************************
Cant get offset of Name in Protocol block!
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** ***
*************************************************************************

Perhaps the symbols for NDIS.SYS really are at the heart of the issue here?
Running a “dt ndis!*” results in no output; however, “dt nt!*” spits out
just plenty (as you would expect).

Thanks for the replies,
-dave cattley

“David Holcomb” wrote in message
news:xxxxx@windbg…

The message only shows up if you really are missing a necessary symbol
file. How exactly are you downloading the symbols from the symbol
server? Do you have the symbol server in your sympath? Are you
debugging a live kernel session or a dump?

Do a ‘lml’ and then do a ‘!sym noisy’ and a ‘.reload /f .’.
That output will tell exactly which symbol file(s) the debugger is
looking for and we can find out if the file is supposed to be on the
Internet public smbol server. If you want to start from scratch either
stop and restart your debugger or do a ‘.reload’ and then retry your
commands.

Any comment?
-dc
“David R. Cattley” wrote in message news:xxxxx@windbg…
>
> David & Nathan,
>
> Thanks for the suggestions. I had actually done Nathans suggestion
prior -
> kill my entire symbol cache and let Windbg get new files from the public
> server. That had not solved the problem and I’m sorry I didn’t mention
that
> in my first post.
>
> As to David’s question about how I get symbols: I have my _NT_SYMBOL_PATH
> environment variable set to the string
>
> SRV*\beetlecat\symbolshttp://msdl.microsoft.com/download/symbols
>
> Plain and simple. The share \beetlecat\symbols is actually on the same
> machine. All that seems to work because after killing the entire cache,
it
> filled up again!
>
> So here is what Windbg emitted in response to David’s suggestion…
>
> kd> lml
> start end module name
> 80a02000 80d6d000 nt (pdb symbols)
>
\beetlecat\symbols\ntoskrnl.pdb\E63229074EAC4B99BE3A727348280AA91\ntoskrnl.
> pdb
> f9bba000 f9c1ed00 NDIS (pdb symbols)
> \beetlecat\symbols\ndis.pdb\1E0AE56CDDCF452B937C5A6CA422BDA51\ndis.pdb
>
> kd> !sym noisy
> noisy mode - symbol prompts on
> kd> .reload /f ndis.sys
> DBGHELP:
> \beetlecat\symbols\ndis.pdb\1E0AE56CDDCF452B937C5A6CA422BDA51\ndis.pdb -
OK
> DBGHELP: NDIS - public symbols -
> \beetlecat\symbols\ndis.pdb\1E0AE56CDDCF452B937C5A6CA422BDA51\ndis.pdb
>
>
> The !ndiskd.protocols command still fails with the string of messages
> indicating that type information is missing:
>
> kd> !ndiskd.protocols
> Protocol ffadd6d0:
>
>

>

>
Your debugger is not using the correct symbols
>

>
In order for this command to work properly, your symbol path
>
must point to .pdb files that have full type information.
>

>
Certain .pdb files (such as the public OS symbols) do not
>
contain the required information. Contact the group that
>
provided you with these symbols if you need this command to
>
work.
>

>

>

> Cant get offset of Name in Protocol block!
>
>

>

>
Your debugger is not using the correct symbols
>

>
In order for this command to work properly, your symbol path
>
must point to .pdb files that have full type information.
>

>
Certain .pdb files (such as the public OS symbols) do not
>
contain the required information. Contact the group that
>
provided you with these symbols if you need this command to
>
work.
>

>

>

>
>

>

>
Your debugger is not using the correct symbols
>

>
In order for this command to work properly, your symbol path
>
must point to .pdb files that have full type information.
>

>
Certain .pdb files (such as the public OS symbols) do not
>
contain the required information. Contact the group that
>
provided you with these symbols if you need this command to
>
work.
>

>

>

>
> Perhaps the symbols for NDIS.SYS really are at the heart of the issue
here?
> Running a "dt ndis!
" results in no output; however, “dt nt!*” spits out
> just plenty (as you would expect).
>
> Thanks for the replies,
> -dave cattley
>
> “David Holcomb” wrote in message
> news:xxxxx@windbg…
>
> The message only shows up if you really are missing a necessary symbol
> file. How exactly are you downloading the symbols from the symbol
> server? Do you have the symbol server in your sympath? Are you
> debugging a live kernel session or a dump?
>
> Do a ‘lml’ and then do a ‘!sym noisy’ and a ‘.reload /f .’.
> That output will tell exactly which symbol file(s) the debugger is
> looking for and we can find out if the file is supposed to be on the
> Internet public smbol server. If you want to start from scratch either
> stop and restart your debugger or do a ‘.reload’ and then retry your
> commands.
>
>
>
>