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 -

FAULTING_IP:
CLASSPNP!ServiceTransferRequest+470
fffff80000cccb30 41f7f3 div eax,r11d<br><br>EXCEPTION_RECORD: ffffd000222efd58 -- (.exr 0xffffd000222efd58)<br>ExceptionAddress: fffff80000cccb30 (CLASSPNP!ServiceTransferRequest+0x0000000000000470)<br> ExceptionCode: c0000094 (Integer divide-by-zero)<br> ExceptionFlags: 00000000<br>NumberParameters: 0<br><br>CONTEXT: ffffd000222ef560 -- (.cxr 0xffffd000222ef560)<br>rax=0000000000001000 rbx=ffffe000024698c0 rcx=ffffe00002f70b90<br>rdx=0000000000000000 rsi=0000000000000000 rdi=ffffe00002807620<br>rip=fffff80000cccb30 rsp=ffffd000222eff90 rbp=0000000000000001<br> r8=0000000000000000 r9=ffffe00002ad0750 r10=ffffe00002f6f000<br>r11=0000000000000000 r12=ffffe00002469770 r13=0000000000000000<br>r14=ffffe00002f71010 r15=0000000000001000<br>iopl=0 nv up ei pl zr na po nc<br>cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010246<br>CLASSPNP!ServiceTransferRequest+0x470:<br>fffff80000cccb30 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 -

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:
ffffd000222eff90 fffff80000ccc29c : ffffe00002469800 ffffe00002ad0750 ffffd000222f0200 fffff80000000000 : CLASSPNP!ServiceTransferRequest+0x470
ffffd000222f0030 fffff80079136f32 : 0000000000000000 ffffe00001823c70 ffffe00002f6f000 0000000000000000 : CLASSPNP!ClassReadWrite+0x11c
ffffd000222f00f0 fffff800011b911c : 0000000000001000 ffffe00002469770 ffffe000024698c0 0000000000000000 : nt!HalExamineMBR+0xc6
ffffd000222f0180 fffff80000d08aeb : 0000000000000000 ffffe000024698c0 fffff80000d02010 ffffe00034426353 : disk!DiskInitFdo+0x14c
ffffd000222f0230 fffff80000d069ca : ffffe00002469800 ffffd0000000000c ffffe00002806620 ffffc00000f5e520 : CLASSPNP!ClassPnpStartDevice+0x46b
ffffd000222f02c0 fffff8007911d17a : 0000000000000000 00000000000000ff ffffe00002f12c20 fffff800793f1f64 : CLASSPNP!ClassDispatchPnp+0x37a
ffffd000222f0400 fffff800794c79fd : ffffe000029c8630 fffff800793f36a7 fffff800790224a8 ffff22c011f333c7 : nt!IoSynchronousCallDriver+0x52
ffffd000222f0460 fffff800005aff7e : fffff800792c6bf0 fffff800792c6c00 ffffd000222f0601 fffff80079116390 : nt!IoForwardIrpSynchronously+0x5d
ffffd000222f0490 fffff800005b9611 : ffffe00002f12c20 ffffe00002f12d80 ffffe00002f12c20 ffffd000222f0620 : partmgr!PmStartDevice+0x6e
ffffd000222f0560 fffff8007946ec7e : ffffe00002f12c20 ffffe00002f76e30 ffffe00002469230 ffffd00021200180 : partmgr!PmPnp+0x121
ffffd000222f05b0 fffff800790e37f1 : ffffe00001fd0060 ffffd000222f0659 0000000000000001 ffffe00002a9e720 : nt!PnpAsynchronousCall+0x102
ffffd000222f05f0 fffff80079470943 : ffffe00002a9e720 ffffe00002a9e720 ffffe00002f76e30 0000000000000004 : nt!PnpStartDevice+0xc5
ffffd000222f06c0 fffff80079470a5b : ffffe00002a9e720 ffffe00002a9e720 0000000000000000 ffffe00002a9e720 : nt!PnpStartDeviceNode+0x147
ffffd000222f0790 fffff8007946f4b6 : ffffe00002a9e720 0000000000000001 0000000000000001 ffffe00000c5cd30 : nt!PipProcessStartPhase1+0x53
ffffd000222f07d0 fffff800795350e3 : 0000000000000000 0000000000000001 0000000000000000 fffff800793eb542 : nt!PipProcessDevNodeTree+0x3ce
ffffd000222f0a50 fffff8007910d2a0 : 0000000100000003 0000000000000000 0000000000000000 0000000000000000 : nt!PiProcessStartSystemDevices+0x87
ffffd000222f0aa0 fffff800790bc1b9 : fffff8007910cf50 ffffd000222f0bd0 0000000000000000 ffffe00000c77b20 : nt!PnpDeviceActionWorker+0x350
ffffd000222f0b50 fffff800790a82e4 : 20b9d98b4820ec83 ffffe0000156b040 ffffe0000156b040 ffffe000009ae940 : nt!ExpWorkerThread+0x2b5
ffffd000222f0c00 fffff8007916f2c6 : ffffd00021280180 ffffe0000156b040 ffffd0002128cf40 5c8b48104b894c00 : nt!PspSystemThreadStartup+0x58
ffffd000222f0c60 0000000000000000 : ffffd000222f1000 ffffd000222eb000 0000000000000000 0000000000000000 : 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
fffff800011b911c 488b4530 mov rax,qword ptr [rbp+30h]<br><br>FAULT_INSTR_CODE: 30458b48<br><br>SYMBOL_STACK_INDEX: 3<br><br>SYMBOL_NAME: disk!DiskInitFdo+14c<br><br>FOLLOWUP_NAME: MachineOwner<br><br>MODULE_NAME: disk<br><br>IMAGE_NAME: disk.sys<br><br>DEBUG_FLR_IMAGE_TIMESTAMP: 5215f883<br><br>STACK_COMMAND: .cxr 0xffffd000222ef560 ; kb<br><br>BUCKET_ID_FUNC_OFFSET: 14c<br><br>FAILURE_BUCKET_ID: AV_disk!DiskInitFdo<br><br>BUCKET_ID: AV_disk!DiskInitFdo<br><br>PRIMARY_PROBLEM_CLASS: AV_disk!DiskInitFdo<br><br>TARGET_TIME: 2017-09-06T09:38:46.000Z<br><br>OSBUILD: 9600<br><br>OSSERVICEPACK: 16422<br><br>SERVICEPACK_NUMBER: 0<br><br>OS_REVISION: 0<br><br>SUITE_MASK: 272<br><br>PRODUCT_TYPE: 3<br><br>OSPLATFORM_TYPE: x64<br><br>OSNAME: Windows 8.1<br><br>OSEDITION: Windows 8.1 Server TerminalServer SingleUserTS<br><br>OS_LOCALE: <br><br>USER_LCID: 0<br><br>OSBUILD_TIMESTAMP: 2013-10-07 09:35:32<br><br>BUILDDATESTAMP_STR: 131006-1505<br><br>BUILDLAB_STR: winblue_gdr<br><br>BUILDOSVER_STR: 6.3.9600.16422<br><br>ANALYSIS_SESSION_ELAPSED_TIME: 1468<br><br>ANALYSIS_SOURCE: KM<br><br>FAILURE_ID_HASH_STRING: km:av_disk!diskinitfdo<br><br>FAILURE_ID_HASH: {5ec8abb6-d141-bf33-9207-abb54f3ee334}<br><br>Followup: MachineOwner<br>---------<br><br>22: kd&gt; lmvm disk<br>Browse full module list<br>start end module name<br>fffff800011ac000 fffff800011c8000 disk (pdb symbols) C:\ProgramData\dbg\sym\disk.pdb\23353E133B224259B49F644F1352A23B2\disk.pdb<br> Loaded symbol image file: disk.sys<br> Image path: \SystemRoot\System32\drivers\disk.sys<br> Image name: disk.sys<br> Browse all global symbols functions data<br> Timestamp: Thu Aug 22 19:39:47 2013 (5215F883)<br> CheckSum: 0001FEF4<br> ImageSize: 0001C000<br> Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4<br><br>Unable to enumerate user-mode unloaded modules, Win32 error 0n30<br>22: kd&gt; .exr 0xffffd000222efd58<br>ExceptionAddress: fffff80000cccb30 (CLASSPNP!ServiceTransferRequest+0x0000000000000470)<br> ExceptionCode: c0000094 (Integer divide-by-zero)<br> ExceptionFlags: 00000000<br>NumberParameters: 0<br>22: kd&gt; .cxr 0xffffd000222ef560<br>rax=0000000000001000 rbx=ffffe000024698c0 rcx=ffffe00002f70b90<br>rdx=0000000000000000 rsi=0000000000000000 rdi=ffffe00002807620<br>rip=fffff80000cccb30 rsp=ffffd000222eff90 rbp=0000000000000001<br> r8=0000000000000000 r9=ffffe00002ad0750 r10=ffffe00002f6f000<br>r11=0000000000000000 r12=ffffe00002469770 r13=0000000000000000<br>r14=ffffe00002f71010 r15=0000000000001000<br>iopl=0 nv up ei pl zr na po nc<br>cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010246<br>CLASSPNP!ServiceTransferRequest+0x470:<br>fffff80000cccb30 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…

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

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.

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
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:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>

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/classpnp/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:xxxxx@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
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:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at
http:

This email message has been delivered safely and archived online by
Mimecast.
For more information please visit http://www.mimecast.com</http:></http:></http:>

Thank you all for your help. I haven’t fix it yet.
It really helps.

Vincent.