Re: [Libusb-win32-devel] BSOD on Windows XP, possibly libusb-win32

[Dan E. <dan...@ne...>]

Doesn't really look like libusb to me. I sometimes get BSODs with libusb
when using it under python, but I think that may be since I started
doing multithreaded stuff. I usually see libusb in the call stack, or at
least usbhub. It occurs when python quits, as if python has held a
handle open and trying to close it is causing a problem. In fact the
stack backtrace usually reveals a NULL pointer somewhere along the line.

Which version of libusb-win32 are you using?

Dan.

Adam Kropelin wrote:
 > A user just reported this XP BSOD in Apcupsd. libusb-win32 is the
 > only kernel driver Apcupsd uses (directly). Is there any evidence in
 > the info below to implicate (or exonerate) libusb-win32? Given the
 > misaligned instruction pointer (EIP should be 32-bit aligned on x86,
 > right?) I'm tempted to suspect bad RAM or another form of memory
 > corruption.    
 >
 > Any ideas from the experts?
 >
 > Thanks!
 > --Adam
 >
 >> I got a BSOD today of 0x0000008e (0xc0000005, 0x805a1993,
 >> 0xb50f7cdc, 0x00000000). Running the kernal dump file through the
 >> Windows Debugger revealed the following:
 >>
 >> 3: kd> !analyze -v
 >>
**********************************************************************
 >> *********
 >> *
 >> *
 >> *                        Bugcheck Analysis
 >> *
 >> *
 >> *
 >>
**********************************************************************
 >> *********
 >>
 >> KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e) This is a very common
 >> bugcheck. Usually the exception address pinpoints the
 >> driver/function that
 >> caused the problem.  Always note this address as well as the link
 >> date of the driver/image that contains this address.
 >> Some common problems are exception code 0x80000003.  This means a
 >> hard coded breakpoint or assertion was hit, but this system was
 >> booted /NODEBUG.  This is not supposed to happen as developers
 >> should never have hardcoded breakpoints in retail code, but ...
 >> If this happens, make sure a debugger gets connected, and the system
 >> is booted /DEBUG.  This will let us see why this breakpoint is
 >> happening. Arguments:
 >> Arg1: c0000005, The exception code that was not handled
 >> Arg2: 805a1993, The address that the exception occurred at
 >> Arg3: b50f7cdc, Trap Frame
 >> Arg4: 00000000
 >>
 >> Debugging Details:
 >> ------------------
 >>
 >> Page 1557c not present in the dump file. Type ".hh dbgerr004" for
 >> details PEB is paged out (Peb.Ldr = 7ffdc00c).  Type ".hh dbgerr001"
 >> for details PEB is paged out (Peb.Ldr = 7ffdc00c).  Type ".hh
 >> dbgerr001" for details
 >>
 >> EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx"
 >> referenced memory at "0x%08lx". The memory could not be "%s".
 >>
 >> FAULTING_IP:
 >> nt!NtRequestWaitReplyPort+3
 >> 805a1993 d09a4d80e874    rcr     byte ptr [edx+74E8804Dh],1
 >>
 >> TRAP_FRAME:  b50f7cdc -- (.trap 0xffffffffb50f7cdc) ErrCode =
 >> 00000002 eax=000000c8 ebx=805a1990 ecx=00000000 edx=0150ecc4
 >> esi=0150ecd0 edi=b50f7d64 eip=805a1993 esp=b50f7d50 ebp=b50f7d64
 >> iopl=0         nv up ei ng nz na po nc cs=0008  ss=0010  ds=0023
 >> es=0023  fs=0030  gs=0000
 >> efl=00010282
 >> nt!NtRequestWaitReplyPort+0x3:
 >> 805a1993 d09a4d80e874    rcr     byte ptr [edx+74E8804Dh],1
 >> ds:0023:76396d11=?? Resetting default scope
 >>
 >> DEFAULT_BUCKET_ID:  DRIVER_FAULT
 >> BUGCHECK_STR:  0x8E
 >> PROCESS_NAME:  apcupsd.exe
 >>
 >> MISALIGNED_IP:
 >> nt!NtRequestWaitReplyPort+3
 >> 805a1993 d09a4d80e874    rcr     byte ptr [edx+74E8804Dh],1
 >>
 >> LAST_CONTROL_TRANSFER:  from 804fe7e3 to 804f9f13
 >>
 >> STACK_TEXT:
 >> b50f78a4 804fe7e3 0000008e c0000005 805a1993 nt!KeBugCheckEx+0x1b
 >> b50f7c6c 80541415 b50f7c88 00000000 b50f7cdc
 >> nt!KiDispatchException+0x3b1
 >> b50f7cd4 805413c6 b50f7d64 805a1993 badb0d00
 >> nt!CommonDispatchException+0x4d b50f7d50 805409ac 00000194 0150ecd0
 >> 0150ecd0 nt!Kei386EoiHelper+0x18a b50f7d50 7c90eb94 00000194 0150ecd0
 >> 0150ecd0 nt!KiFastCallEntry+0xfc
 >> WARNING: Frame IP not in any known module. Following frames may be
 >> wrong. 0150ee08 00000000 00000000 00000000 00000000 0x7c90eb94
 >>
 >> STACK_COMMAND:  kb
 >>
 >> FOLLOWUP_IP:
 >> nt!NtRequestWaitReplyPort+3
 >> 805a1993 d09a4d80e874    rcr     byte ptr [edx+74E8804Dh],1
 >>
 >> SYMBOL_STACK_INDEX:  0
 >> SYMBOL_NAME:  nt!NtRequestWaitReplyPort+3
 >> FOLLOWUP_NAME:  MachineOwner
 >> IMAGE_NAME:  hardware
 >> DEBUG_FLR_IMAGE_TIMESTAMP:  0
 >> MODULE_NAME: hardware
 >> FAILURE_BUCKET_ID:  IP_MISALIGNED
 >> BUCKET_ID:  IP_MISALIGNED
 >> Followup: MachineOwner
 >
 >
 >
 >
------------------------------------------------------------------------
-
 > This SF.net email is sponsored by: Splunk Inc.
 > Still grepping through log files to find problems?  Stop.
 > Now Search log events and configuration files using AJAX and a
 > browser.
 > Download your FREE copy of Splunk now >> http://get.splunk.com/
 > _______________________________________________
 > Libusb-win32-devel mailing list
 > Lib...@li...
 > https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel