Menu
▾
▴
Re: [Libusb-win32-devel] BSOD on Windows XP, possibly libusb-win32
|
From: Adam K. <akr...@ro...> - 2007-11-06 18:59:51
|
Thanks for the comments, Dan. I'm distributing libusb-win32 snapshot 20060827. The x32 components are cross-compiled using mingw32 from Linux, and the x64 components are distributed from Stephan's binary package. I should consider upgrading to 0.1.12.1, but have resisted since I have no reported issues with the snapshot (until now, possibly). --Adam Dan Ellis wrote: > 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 > > > ------------------------------------------------------------------------- > 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 |
