Re: Bugcode Parameters
nospam_at_cristalink.com
Date: 09/08/04
- Next message: Beverly Brown: "Re: DeviceIoControl, Overlapped vs Non-Overlapped: How it affects driver design?"
- Previous message: Hemant Kumar: "Re: device to sys files"
- In reply to: Bob: "Re: Bugcode Parameters"
- Next in thread: Bob: "Re: Bugcode Parameters"
- Reply: Bob: "Re: Bugcode Parameters"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 8 Sep 2004 15:34:26 +1200
"Bob" <nobody@nowhere.nohow> wrote in message
news:413e707d.15906356@news.compuserve.com...
> On Wed, 8 Sep 2004 10:51:50 +1200, <nospam@cristalink.com> wrote:
>
> First, thank you for the earlier suggestion. It turned out to be very
> useful once I got it all set up. I use SoftIce, I'm not very familiar
> with WinDbg, but it was indeed quite helpful.
>
>>This means nothing because you have no symbols installed.
>
> Well, your knowledge of WinDbg is certainly better than mine, but I
> have to question whether or not it means "nothing". I've gotten dumps
> from two more machines and all are reporting HIDCLASS+2185 as the
> culprit. The only other possibility I can see is that it's getting an
> address and deciding the it's my HidClass + 2185, but I've certainly
> rebooted and fussed around with it enough that my HidClass will have
> moved. The pointers and addresses in the calls are all different, but
> the addresses stated as HIDCLASS+xxxx or nt+xxxx are the same, and if
> I trace the addresses through the stack dump in SP2 HidClass, I indeed
> end up at HIDCLASS+2140 (the routine that includes +2185) as expected.
Well, if it's your HidClass, then HidClass+2185 is most likely correct, and
the problem is in your HidClass driver. I thought that maybe there's some
Microsoft's HidClass, and I doubted that it could cause the problem. I have
an impression that sometimes, with no symbols available, WinDbg may display
an address as SomeSystemDriver+SomeBigOffset. The resulting value lies well
beyond SomeSystemDriver, in some other driver whose name is not available.
You should compile your drivers with full debug info, even release versions,
and keep .pdb files for each driver you release. All the debug info usually
goes to .pdb, so it's ok in terms of security. If you have a .pdb file for
your driver, you can load it into WinDbg, and the latter will tell you the
source file/line number, not just some obscure offset. If you don't have
.pdb, then you better re-build your driver with .pdb and make it crash
again.
>
>>Set the following environment variable:
>>
>>_NT_SYMBOL_PATH=symsrv*symsrv.dll*C:\WINDOWS\Symbols\localcache*http://msdl.microsoft.com/download/symbols
>
> Yes, thanks. But won't that require an Internet connection to the
> machine that has WinDbg on it? My dialup is only connected to my Win98
> machine. I may move the modem and give it a try, but I've managed to
> find a local machine that will both crash and has a T1 connection,
> more than likely I'll go there where I can make it happen and I'll get
> the symbols at the same time.
If WinDbg already points to your driver, then I don't think you need system
symbols. You need your own ones.
>
> Thanks again for the WinDbg suggestion! It's much appreciated!
>
> - Bob
>
- Next message: Beverly Brown: "Re: DeviceIoControl, Overlapped vs Non-Overlapped: How it affects driver design?"
- Previous message: Hemant Kumar: "Re: device to sys files"
- In reply to: Bob: "Re: Bugcode Parameters"
- Next in thread: Bob: "Re: Bugcode Parameters"
- Reply: Bob: "Re: Bugcode Parameters"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
