RE: USB to Serial Port && Kernal BSODs
- From: "Buddy Lott" <buddylott@xxxxxxxxxxxxx>
- Date: Fri, 6 Jan 2006 06:10:03 -0800
1 clarification .... I am talking to custom hardware but the usb to serial
cable I am using is commercially available. The driver for this cable is
theirs.
I have tried setting the symbol path serverl times and nothing seems to
change.
I sort of understand what the Bug Check infor is telling me, but not why it
would happen in my code (if it is happening in my code). So far, I have only
been able to reproduce the problem on a limited number of machines.
Here is the latest analyze info:
Loading Dump File [C:\WINDOWS\MEMORY.DMP]
Kernel Complete Dump File: Full address space is available
Symbol search path is:
C:\work\Projects\BACnet_Router\BACnetRouterTools\Debug;C:\work\Projects\BACnet_Router\BACnetRouterTools\Release
Executable search path is:
C:\work\Projects\BACnet_Router\BACnetRouterTools\Debug
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
ntkrnlpa.exe -
Windows XP Kernel Version 2600 (Service Pack 2) UP Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp_sp2_gdr.050301-1519
Kernel base = 0x804d7000 PsLoadedModuleList = 0x805531a0
Debug session time: Thu Jan 5 12:37:50.782 2006 (GMT-5)
System Uptime: 0 days 3:59:07.819
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
ntkrnlpa.exe -
Loading Kernel Symbols
...........................................................................................................................................................
Loading unloaded module list
.................
Loading User Symbols
............................................................................................................
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck D0, {13c80004, 2, 1, 80541f69}
***** Kernel symbols are WRONG. Please fix symbols to do analysis.
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
ntdll.dll -
*************************************************************************
*** ***
*** ***
*** 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. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
Followup: MachineOwner
---------
kd> !analyze -v
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************
DRIVER_CORRUPTED_MMPOOL (d0)
Arguments:
Arg1: 13c80004, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: 80541f69, address which referenced memory
An attempt was made to access a pageable (or completely invalid) address at
an
interrupt request level (IRQL) that is too high. This is
caused by drivers that have corrupted the system pool. Run the driver
verifier against any new (or suspect) drivers, and if that doesn't turn up
the culprit, then use gflags to enable special pool. You can also set
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory
Management\ProtectNonPagedPool
to a DWORD 1 value and reboot. Then the system will unmap freed nonpaged
pool,
preventing drivers (although not DMA-hardware) from corrupting the pool.
Debugging Details:
------------------
***** Kernel symbols are WRONG. Please fix symbols to do analysis.
*************************************************************************
*** ***
*** ***
*** 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. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
MODULE_NAME: nt
FAULTING_MODULE: 804d7000 nt
DEBUG_FLR_IMAGE_TIMESTAMP: 42250a1d
WRITE_ADDRESS: unable to get nt!MmSpecialPoolStart
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPoolCodeStart
unable to get nt!MmPoolCodeEnd
13c80004
CURRENT_IRQL: 2
FAULTING_IP:
nt!ExRaiseStatus+269
80541f69 894804 mov [eax+0x4],ecx
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0xD0
LAST_CONTROL_TRANSFER: from 80541f69 to 8053f853
STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be
wrong.
ec960b2c 80541f69 badb0d00 00000000 00000c2c nt!Kei386EoiHelper+0x27db
ec960bdc 80544653 00000000 d05d9000 00000000 nt!ExRaiseStatus+0x269
ec960c44 805327d0 0000000c 00000001 20206f49 nt!ExAllocatePoolWithTag+0x5d3
ec960c68 80574936 00000004 00000e38 20206f49
nt!ExAllocatePoolWithQuotaTag+0x46
ec960d00 8056d326 000004c0 00000624 00000000 nt!NtWriteFile+0x3896
ec960d34 8053c808 000004c0 00000624 00000000 nt!NtDeviceIoControlFile+0x2a
ec960d64 7c90eb94 badb0d00 01e0f4e0 00000000
nt!KeReleaseInStackQueuedSpinLockFromDpcLevel+0xb14
ec960d68 badb0d00 01e0f4e0 00000000 00000000 ntdll!KiFastSystemCallRet
ec960d6c 01e0f4e0 00000000 00000000 00000000 0xbadb0d00
ec960d70 00000000 00000000 00000000 00000000 0x1e0f4e0
STACK_COMMAND: .bugcheck ; kb
FOLLOWUP_NAME: MachineOwner
BUCKET_ID: WRONG_SYMBOLS
Followup: MachineOwner
---------
--
Buddy Lott
""Jeffrey Tan[MSFT]"" wrote:
> Hi Buddy,
>
> Thanks for your post.
>
> BSOD is the unhandled and unexpected exception thrown in kernel mode,
> normally caused by impropery driver or kernel components. Currently, from
> the information you provided, it is hard to analysis out what is the root
> cause. I suspect it is the custom hardware driver caused this problem(your
> user mode VC++ application may only caused certain part of this hardware
> driver code to run, and caused the crash).
>
> Now, I think we have to use Windbg to load this BSOD dump file and get some
> information from it. After loading this dump file with Windbg, you may use
> !analyze -v command to display the bugcheck code. After getting this
> bugcheck code, you can look it up in "Bug Check Code Reference" in windbg
> help(this reference also existed in MSDN as topic "Bug Check Codes") For
> detailed steps about troubleshooting BSOD, please refer to "Analyzing a
> Kernel-Mode Dump File with WinDbg" in windbg help.
>
> Note: before using the windbg, make sure the symbols is setup correctly.
>
> Hope this helps
>
> Best regards,
> Jeffrey Tan
> Microsoft Online Partner Support
> Get Secure! - www.microsoft.com/security
> This posting is provided "as is" with no warranties and confers no rights.
>
>
.
- Follow-Ups:
- Re: USB to Serial Port && Kernal BSODs
- From: Alexander Grigoriev
- Re: USB to Serial Port && Kernal BSODs
- From: Doron Holan [MS]
- Re: USB to Serial Port && Kernal BSODs
- References:
- RE: USB to Serial Port && Kernal BSODs
- From: "Jeffrey Tan[MSFT]"
- RE: USB to Serial Port && Kernal BSODs
- Prev by Date: Static global HHOOK instead of shared segment variable
- Next by Date: Re: USB to Serial Port && Kernal BSODs
- Previous by thread: RE: USB to Serial Port && Kernal BSODs
- Next by thread: Re: USB to Serial Port && Kernal BSODs
- Index(es):
Relevant Pages
|
Loading