Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

Monthly Seminars at OSR Headquarters

East Coast USA
Windows Internals and SW Drivers, Dulles (Sterling) VA, 13 November 2017

Kernel Debugging & Crash Analysis for Windows, Nashua (Amherst) NH, 4 December 2017

Writing WDF Drivers I: Core Concepts, Nashua (Amherst) NH, 8 January 2018

WDF Drivers II: Advanced Implementation Techniques, Nashua (Amherst) NH, 15 January 2018


Go Back   OSR Online Lists > ntdev
Welcome, Guest
You must login to post to this list
  Message 1 of 6  
06 Sep 17 06:06
Vincent Jin
xxxxxx@gmail.com
Join Date: 30 Nov 2011
Posts To This List: 11
Storport driver issue

I'm debugging a storport driver. After scsi commands SCSIOP_REPORT_LUNS, SCSIOP_INQUIRY and SCSIOP_READ_CAPACITY. There's a error as following. It reported a exception with "Integer divide-by-zero". Is there any way to further debug on this? Thanks. ====================================================== KDTARGET: Refreshing KD connection *** Fatal System Error: 0x0000007e (0xFFFFFFFFC0000094,0xFFFFF80000CCCB30,0xFFFFD000222EFD58,0xFFFFD000222EF560) Break instruction exception - code 80000003 (first chance) A fatal system error has occurred. Debugger entered on first try; Bugcheck callbacks have not been invoked. A fatal system error has occurred. nt!DbgBreakPointWithStatus: fffff800`7916f890 cc int 3 22: kd> !analyze -v Connected to Windows 8.1 9600 x64 target at (Wed Sep 6 17:40:22.836 2017 (UTC + 8:00)), ptr64 TRUE Loading Kernel Symbols ............................................................... ...................................... Loading User Symbols Loading unloaded module list ...Unable to enumerate user-mode unloaded modules, Win32 error 0n30 ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e) 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. Arguments: Arg1: ffffffffc0000094, The exception code that was not handled Arg2: fffff80000cccb30, The address that the exception occurred at Arg3: ffffd000222efd58, Exception Record Address Arg4: ffffd000222ef560, Context Record Address Debugging Details: ------------------ DUMP_CLASS: 1 DUMP_QUALIFIER: 0 BUILD_VERSION_STRING: 6.3.9600.16422 (winblue_gdr.131006-1505) DUMP_TYPE: 0 BUGCHECK_P1: ffffffffc0000094 BUGCHECK_P2: fffff80000cccb30 BUGCHECK_P3: ffffd000222efd58 BUGCHECK_P4: ffffd000222ef560 EXCEPTION_CODE: (NTSTATUS) 0xc0000094 - <Unable to get error code text> FAULTING_IP: CLASSPNP!ServiceTransferRequest+470 fffff800`00cccb30 41f7f3 div eax,r11d EXCEPTION_RECORD: ffffd000222efd58 -- (.exr 0xffffd000222efd58) ExceptionAddress: fffff80000cccb30 (CLASSPNP!ServiceTransferRequest+0x0000000000000470) ExceptionCode: c0000094 (Integer divide-by-zero) ExceptionFlags: 00000000 NumberParameters: 0 CONTEXT: ffffd000222ef560 -- (.cxr 0xffffd000222ef560) rax=0000000000001000 rbx=ffffe000024698c0 rcx=ffffe00002f70b90 rdx=0000000000000000 rsi=0000000000000000 rdi=ffffe00002807620 rip=fffff80000cccb30 rsp=ffffd000222eff90 rbp=0000000000000001 r8=0000000000000000 r9=ffffe00002ad0750 r10=ffffe00002f6f000 r11=0000000000000000 r12=ffffe00002469770 r13=0000000000000000 r14=ffffe00002f71010 r15=0000000000001000 iopl=0 nv up ei pl zr na po nc cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010246 CLASSPNP!ServiceTransferRequest+0x470: fffff800`00cccb30 41f7f3 div eax,r11d Resetting default scope CPU_COUNT: 38 CPU_MHZ: 7d0 CPU_VENDOR: GenuineIntel CPU_FAMILY: 6 CPU_MODEL: 3f CPU_STEPPING: 2 CPU_MICROCODE: 6,3f,2,0 (F,M,S,R) SIG: 3A'00000000 (cache) 3A'00000000 (init) DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT BUGCHECK_STR: AV PROCESS_NAME: System CURRENT_IRQL: 0 ERROR_CODE: (NTSTATUS) 0xc0000094 - <Unable to get error code text> EXCEPTION_CODE_STR: c0000094 ANALYSIS_SESSION_HOST: VINCE-PC ANALYSIS_SESSION_TIME: 09-06-2017 17:40:23.0656 ANALYSIS_VERSION: 10.0.15063.400 amd64fre LOCK_ADDRESS: fffff800792ea360 -- (!locks fffff800792ea360) Resource @ nt!PiEngineLock (0xfffff800792ea360) Exclusively owned Contention Count = 2 NumberOfExclusiveWaiters = 1 Threads: ffffe0000156b040-01<*> Threads Waiting On Exclusive Access: ffffe0000156c880 1 total locks PNP_TRIAGE: Lock address : 0xfffff800792ea360 Thread Count : 1 Thread address: 0xffffe0000156b040 Thread wait : 0x157c LAST_CONTROL_TRANSFER: from fffff800791f10da to fffff8007916f890 STACK_TEXT: ffffd000`222eff90 fffff800`00ccc29c : ffffe000`02469800 ffffe000`02ad0750 ffffd000`222f0200 fffff800`00000000 : CLASSPNP!ServiceTransferRequest+0x470 ffffd000`222f0030 fffff800`79136f32 : 00000000`00000000 ffffe000`01823c70 ffffe000`02f6f000 00000000`00000000 : CLASSPNP!ClassReadWrite+0x11c ffffd000`222f00f0 fffff800`011b911c : 00000000`00001000 ffffe000`02469770 ffffe000`024698c0 00000000`00000000 : nt!HalExamineMBR+0xc6 ffffd000`222f0180 fffff800`00d08aeb : 00000000`00000000 ffffe000`024698c0 fffff800`00d02010 ffffe000`34426353 : disk!DiskInitFdo+0x14c ffffd000`222f0230 fffff800`00d069ca : ffffe000`02469800 ffffd000`0000000c ffffe000`02806620 ffffc000`00f5e520 : CLASSPNP!ClassPnpStartDevice+0x46b ffffd000`222f02c0 fffff800`7911d17a : 00000000`00000000 00000000`000000ff ffffe000`02f12c20 fffff800`793f1f64 : CLASSPNP!ClassDispatchPnp+0x37a ffffd000`222f0400 fffff800`794c79fd : ffffe000`029c8630 fffff800`793f36a7 fffff800`790224a8 ffff22c0`11f333c7 : nt!IoSynchronousCallDriver+0x52 ffffd000`222f0460 fffff800`005aff7e : fffff800`792c6bf0 fffff800`792c6c00 ffffd000`222f0601 fffff800`79116390 : nt!IoForwardIrpSynchronously+0x5d ffffd000`222f0490 fffff800`005b9611 : ffffe000`02f12c20 ffffe000`02f12d80 ffffe000`02f12c20 ffffd000`222f0620 : partmgr!PmStartDevice+0x6e ffffd000`222f0560 fffff800`7946ec7e : ffffe000`02f12c20 ffffe000`02f76e30 ffffe000`02469230 ffffd000`21200180 : partmgr!PmPnp+0x121 ffffd000`222f05b0 fffff800`790e37f1 : ffffe000`01fd0060 ffffd000`222f0659 00000000`00000001 ffffe000`02a9e720 : nt!PnpAsynchronousCall+0x102 ffffd000`222f05f0 fffff800`79470943 : ffffe000`02a9e720 ffffe000`02a9e720 ffffe000`02f76e30 00000000`00000004 : nt!PnpStartDevice+0xc5 ffffd000`222f06c0 fffff800`79470a5b : ffffe000`02a9e720 ffffe000`02a9e720 00000000`00000000 ffffe000`02a9e720 : nt!PnpStartDeviceNode+0x147 ffffd000`222f0790 fffff800`7946f4b6 : ffffe000`02a9e720 00000000`00000001 00000000`00000001 ffffe000`00c5cd30 : nt!PipProcessStartPhase1+0x53 ffffd000`222f07d0 fffff800`795350e3 : 00000000`00000000 00000000`00000001 00000000`00000000 fffff800`793eb542 : nt!PipProcessDevNodeTree+0x3ce ffffd000`222f0a50 fffff800`7910d2a0 : 00000001`00000003 00000000`00000000 00000000`00000000 00000000`00000000 : nt!PiProcessStartSystemDevices+0x87 ffffd000`222f0aa0 fffff800`790bc1b9 : fffff800`7910cf50 ffffd000`222f0bd0 00000000`00000000 ffffe000`00c77b20 : nt!PnpDeviceActionWorker+0x350 ffffd000`222f0b50 fffff800`790a82e4 : 20b9d98b`4820ec83 ffffe000`0156b040 ffffe000`0156b040 ffffe000`009ae940 : nt!ExpWorkerThread+0x2b5 ffffd000`222f0c00 fffff800`7916f2c6 : ffffd000`21280180 ffffe000`0156b040 ffffd000`2128cf40 5c8b4810`4b894c00 : nt!PspSystemThreadStartup+0x58 ffffd000`222f0c60 00000000`00000000 : ffffd000`222f1000 ffffd000`222eb000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16 THREAD_SHA1_HASH_MOD_FUNC: fe81ee73fe3449bf18bf7e7c81a6958b4b26dd65 THREAD_SHA1_HASH_MOD_FUNC_OFFSET: c12a3da1e0355f1883904c6a79053d2729808eeb THREAD_SHA1_HASH_MOD: 72e27f5b00589b1f6faaa3161792d96f98b4913b FOLLOWUP_IP: disk!DiskInitFdo+14c fffff800`011b911c 488b4530 mov rax,qword ptr [rbp+30h] FAULT_INSTR_CODE: 30458b48 SYMBOL_STACK_INDEX: 3 SYMBOL_NAME: disk!DiskInitFdo+14c FOLLOWUP_NAME: MachineOwner MODULE_NAME: disk IMAGE_NAME: disk.sys DEBUG_FLR_IMAGE_TIMESTAMP: 5215f883 STACK_COMMAND: .cxr 0xffffd000222ef560 ; kb BUCKET_ID_FUNC_OFFSET: 14c FAILURE_BUCKET_ID: AV_disk!DiskInitFdo BUCKET_ID: AV_disk!DiskInitFdo PRIMARY_PROBLEM_CLASS: AV_disk!DiskInitFdo TARGET_TIME: 2017-09-06T09:38:46.000Z OSBUILD: 9600 OSSERVICEPACK: 16422 SERVICEPACK_NUMBER: 0 OS_REVISION: 0 SUITE_MASK: 272 PRODUCT_TYPE: 3 OSPLATFORM_TYPE: x64 OSNAME: Windows 8.1 OSEDITION: Windows 8.1 Server TerminalServer SingleUserTS OS_LOCALE: USER_LCID: 0 OSBUILD_TIMESTAMP: 2013-10-07 09:35:32 BUILDDATESTAMP_STR: 131006-1505 BUILDLAB_STR: winblue_gdr BUILDOSVER_STR: 6.3.9600.16422 ANALYSIS_SESSION_ELAPSED_TIME: 1468 ANALYSIS_SOURCE: KM FAILURE_ID_HASH_STRING: km:av_disk!diskinitfdo FAILURE_ID_HASH: {5ec8abb6-d141-bf33-9207-abb54f3ee334} Followup: MachineOwner --------- 22: kd> lmvm disk Browse full module list start end module name fffff800`011ac000 fffff800`011c8000 disk (pdb symbols) C:\ProgramData\dbg\sym\disk.pdb\23353E133B224259B49F644F1352A23B2\disk.pdb Loaded symbol image file: disk.sys Image path: \SystemRoot\System32\drivers\disk.sys Image name: disk.sys Browse all global symbols functions data Timestamp: Thu Aug 22 19:39:47 2013 (5215F883) CheckSum: 0001FEF4 ImageSize: 0001C000 Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4 Unable to enumerate user-mode unloaded modules, Win32 error 0n30 22: kd> .exr 0xffffd000222efd58 ExceptionAddress: fffff80000cccb30 (CLASSPNP!ServiceTransferRequest+0x0000000000000470) ExceptionCode: c0000094 (Integer divide-by-zero) ExceptionFlags: 00000000 NumberParameters: 0 22: kd> .cxr 0xffffd000222ef560 rax=0000000000001000 rbx=ffffe000024698c0 rcx=ffffe00002f70b90 rdx=0000000000000000 rsi=0000000000000000 rdi=ffffe00002807620 rip=fffff80000cccb30 rsp=ffffd000222eff90 rbp=0000000000000001 r8=0000000000000000 r9=ffffe00002ad0750 r10=ffffe00002f6f000 r11=0000000000000000 r12=ffffe00002469770 r13=0000000000000000 r14=ffffe00002f71010 r15=0000000000001000 iopl=0 nv up ei pl zr na po nc cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010246 CLASSPNP!ServiceTransferRequest+0x470: fffff800`00cccb30 41f7f3 div eax,r11d 22: kd> .reboot Shutdown occurred at (Wed Sep 6 17:48:33.515 2017 (UTC + 8:00))...unloading all symbol tables. Using NET for debugging Opened WinSock 2.0 Waiting to reconnect...
  Message 2 of 6  
06 Sep 17 10:55
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5949
List Moderator
Storport driver issue

Wow. Didn't get very far, did it. You have the symbols and sources for the StorPort driver you're debugging? That should make it more or less straight-forward, I would think. Peter OSR @OSRDrivers
  Message 3 of 6  
06 Sep 17 21:36
Vincent Jin
xxxxxx@gmail.com
Join Date: 30 Nov 2011
Posts To This List: 11
Storport driver issue

Yes. I have the code for the driver. Actually I've checked the value set in the storport routines, but I couldn't find out which value was wrong. The stack I've posted didn't give out enough information related to the my driver.
  Message 4 of 6  
11 Sep 17 10:54
David Boyce
xxxxxx@becrypt.com
Join Date: 19 Mar 2015
Posts To This List: 70
Storport driver issue

You've probably found the problem by now, but the following may help if you haven't. The stack you've posted *can* tell you more if you have the corresponding assembly listing and link map for the driver. Assembly listings are obtained at compilation time, using something like /FAcs (other listing output settings are available, but this is the most useful IMO). Link Maps are obtained at LINK time using /MAP Your task is to find the location corresponding to the symbol "_ServiceTransferRequest" in the Assembler Files - note the leading underscore; the Link Map will help in this search, but a brute force search in the listings should suffice; then add 0x470 to the symbol's offset, and find the corresponding code offset in the assembly listing. The instruction immediately before this location should be the "div eax,r11d" reported in the dump. Examination of the accompanying source code in the listing should show you where that divide-by-0 value is coming from. -----Original Message----- From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com xxxxx@lists.osr.com Sent: 07 September 2017 02:34 To: Windows System Software Devs Interest List <xxxxx@lists.osr.com> Subject: RE:[ntdev] Storport driver issue Yes. I have the code for the driver. Actually I've checked the value set in the storport routines, but I couldn't find out which value was wrong. The stack I've posted didn't give out enough information related to the my driver. --- NTDEV is sponsored by OSR Visit the list online at: <http://www.osronline.com/showlists.cfm?list=ntdev> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at <http://www.osr.com/seminars> To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer> --
  Message 5 of 6  
12 Sep 17 11:18
Scott Noone
xxxxxx@osr.com
Join Date:
Posts To This List: 1335
List Moderator
Storport driver issue

The crash is in ClassPnp!ServiceTransferRequest, which is an OS component. Thankfully, the source code to the ClassPnP driver is on GitHub so you can search for the offending div. I suspect (but don't know) that it's here: https://github.com/Microsoft/Windows-driver-samples/blob/master/storage/class/cla sspnp/src/class.c#L3457 Which would indicate a problem with the adapter reporting its maximum transfer length. -scott OSR @OSRDrivers <%%merge inmail_.HdrFrom_%% xxxxx@lists.osr.com> wrote in message news:225224@ntdev... You've probably found the problem by now, but the following may help if you haven't. The stack you've posted *can* tell you more if you have the corresponding assembly listing and link map for the driver. Assembly listings are obtained at compilation time, using something like /FAcs (other listing output settings are available, but this is the most useful IMO). Link Maps are obtained at LINK time using /MAP Your task is to find the location corresponding to the symbol "_ServiceTransferRequest" in the Assembler Files - note the leading underscore; the Link Map will help in this search, but a brute force search in the listings should suffice; then add 0x470 to the symbol's offset, and find the corresponding code offset in the assembly listing. The instruction immediately before this location should be the "div eax,r11d" reported in the dump. Examination of the accompanying source code in the listing should show you where that divide-by-0 value is coming from. -----Original Message----- From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com xxxxx@lists.osr.com Sent: 07 September 2017 02:34 To: Windows System Software Devs Interest List <xxxxx@lists.osr.com> Subject: RE:[ntdev] Storport driver issue Yes. I have the code for the driver. Actually I've checked the value set in the storport routines, but I couldn't find out which value was wrong. The stack I've posted didn't give out enough information related to the my driver. --- NTDEV is sponsored by OSR Visit the list online at: <http://www.osronline.com/showlists.cfm?list=ntdev> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at <http://www.osr.com/seminars> To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer> This email message has been delivered safely and archived online by Mimecast. For more information please visit http://www.mimecast.com
  Message 6 of 6  
14 Sep 17 23:53
Vincent Jin
xxxxxx@gmail.com
Join Date: 30 Nov 2011
Posts To This List: 11
Storport driver issue

Thank you all for your help. I haven't fix it yet. It really helps. Vincent.
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntdev list to be able to post.

All times are GMT -5. The time now is 03:04.


Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license