Hi,
I am new to driver development. I have written a miniport driver which loads correctly.
When i try to run IO using IO meter/any application, the driver gives BSOD. These BSOD error code change every time, some time storport.sys or USBPORT.sys or classpnp.sys etc . It doesn’t show error in my driver code.
What is the wrong thing i am doing in my driver? How can i debug the driver?
Thanks,
Amogha
IF you want us to help, you to understand the reason of CRASH then you have
to give debug logs.
>>… It doesn’t show error in my driver code.
It is not showing error in your driver code because you do not have correct
source & symbols.
>>…How can i debug the driver?
There are lot of tools available to debug kernel level. Windbg is one of
them. Do google to know how to use and debug. If you are developing kernel
level driver then it is mandatory to be familiar with at least one debugging
tool.
On Mon, Mar 28, 2011 at 2:01 PM, wrote:
> Hi,
>
> I am new to driver development. I have written a miniport driver which
> loads correctly.
>
> When i try to run IO using IO meter/any application, the driver gives BSOD.
> These BSOD error code change every time, some time storport.sys or
> USBPORT.sys or classpnp.sys etc . It doesn’t show error in my driver code.
>
> What is the wrong thing i am doing in my driver? How can i debug the
> driver?
>
> Thanks,
> Amogha
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Hi sarbojit,
I am using WinDbg for debugging driver. I have fixed many issues in my driver and now it loads successfully. The problem occurs when i try to run IO, resulting in BSOD with different bug checks. Below is the log for your reference.
BugCheck D1, {24, 2, 0, 82fb7357}
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 00000024, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 82fb7357, address which referenced memory
Missing image name, possible paged-out or corrupt data.
Unable to read KLDR_DATA_TABLE_ENTRY at 00000000 - Win32 error 0n30
WARNING: .reload failed, module list may be incomplete
Missing image name, possible paged-out or corrupt data.
Unable to read KLDR_DATA_TABLE_ENTRY at 00000000 - Win32 error 0n30
WARNING: .reload failed, module list may be incomplete
READ_ADDRESS: 00000024
CURRENT_IRQL: 2
FAULTING_IP:
storport!RaidUnitReleaseIrp+11
82fb7357 8b7e24 mov edi,dword ptr [esi+24h]
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0xD1
PROCESS_NAME: System
TRAP_FRAME: 8cd52b60 -- (.trap 0xffffffff8cd52b60)
ErrCode = 00000000
eax=86e5eb10 ebx=86e5eb10 ecx=86e5ebc8 edx=00000000 esi=00000000 edi=86e5ecc4
eip=82fb7357 esp=8cd52bd4 ebp=8cd52be0 iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
storport!RaidUnitReleaseIrp+0x11:
82fb7357 8b7e24 mov edi,dword ptr [esi+24h] ds:0023:00000024=????????
Resetting default scope
LAST_CONTROL_TRANSFER: from 8292ae71 to 828b9394
STACK_TEXT:
8cd5272c 8292ae71 00000003 57a2022a 00000065 nt!RtlpBreakWithStatusInstruction
8cd5277c 8292b96d 00000003 00000024 82fb7357 nt!KiBugCheckDebugBreak+0x1c
8cd52b40 828947eb 0000000a 00000024 00000002 nt!KeBugCheck2+0x68b
8cd52b40 82fb7357 0000000a 00000024 00000002 nt!KiTrap0E+0x2cf
8cd52be0 82fb7806 86e5eb10 86e5eb10 86e5ecc4 storport!RaidUnitReleaseIrp+0x11
8cd52c1c 82fb7a65 8750eac0 856e9008 8559b0e8 storport!RaUnitAsyncError+0x15e
8cd52c50 82fa91d9 8750eac0 8559b0a4 8cd3b884 storport!RaidUnitCompleteRequest+0x101
8cd52c78 828b63b5 8559b0a4 8559b030 00000000 storport!RaidpAdapterDpcRoutine+0x51
8cd52cd4 828b6218 8cd36120 8cd3b800 00000000 nt!KiExecuteAllDpcs+0xf9
8cd52d20 828b6038 00000000 0000000e 00000000 nt!KiRetireDpcList+0xd5
8cd52d24 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x38
STACK_COMMAND: kb
FOLLOWUP_IP:
storport!RaidUnitReleaseIrp+11
82fb7357 8b7e24 mov edi,dword ptr [esi+24h]
SYMBOL_STACK_INDEX: 4
SYMBOL_NAME: storport!RaidUnitReleaseIrp+11
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: storport
IMAGE_NAME: storport.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bc736
FAILURE_BUCKET_ID: 0xD1_storport!RaidUnitReleaseIrp+11
BUCKET_ID: 0xD1_storport!RaidUnitReleaseIrp+11
Followup: MachineOwner
How i need to debug this kind of issues?
Thanks,
Amogha
OK…
As per the log your driver is trying to access pageable memory at Dispatch
level. Which is not allowed.
On Mon, Mar 28, 2011 at 2:38 PM, wrote:
> Hi sarbojit,
>
> I am using WinDbg for debugging driver. I have fixed many issues in my
> driver and now it loads successfully. The problem occurs when i try to run
> IO, resulting in BSOD with different bug checks. Below is the log for your
> reference.
>
> BugCheck D1, {24, 2, 0, 82fb7357}
>
> DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
> An attempt was made to access a pageable (or completely invalid) address at
> an
> interrupt request level (IRQL) that is too high. This is usually
> caused by drivers using improper addresses.
> If kernel debugger is available get stack backtrace.
> Arguments:
> Arg1: 00000024, memory referenced
> Arg2: 00000002, IRQL
> Arg3: 00000000, value 0 = read operation, 1 = write operation
> Arg4: 82fb7357, address which referenced memory
>
> Debugging Details:
> ------------------
>
> Missing image name, possible paged-out or corrupt data.
> Unable to read KLDR_DATA_TABLE_ENTRY at 00000000 - Win32 error 0n30
> WARNING: .reload failed, module list may be incomplete
> Missing image name, possible paged-out or corrupt data.
> Unable to read KLDR_DATA_TABLE_ENTRY at 00000000 - Win32 error 0n30
> WARNING: .reload failed, module list may be incomplete
>
> READ_ADDRESS: 00000024
> CURRENT_IRQL: 2
> FAULTING_IP:
> storport!RaidUnitReleaseIrp+11
> 82fb7357 8b7e24 mov edi,dword ptr [esi+24h]
>
> DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
> BUGCHECK_STR: 0xD1
> PROCESS_NAME: System
> TRAP_FRAME: 8cd52b60 – (.trap 0xffffffff8cd52b60)
>
> ErrCode = 00000000
> eax=86e5eb10 ebx=86e5eb10 ecx=86e5ebc8 edx=00000000 esi=00000000
> edi=86e5ecc4
> eip=82fb7357 esp=8cd52bd4 ebp=8cd52be0 iopl=0 nv up ei pl zr na pe
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010246
> storport!RaidUnitReleaseIrp+0x11:
> 82fb7357 8b7e24 mov edi,dword ptr [esi+24h]
> ds:0023:00000024=???
> Resetting default scope
>
> LAST_CONTROL_TRANSFER: from 8292ae71 to 828b9394
> STACK_TEXT:
> 8cd5272c 8292ae71 00000003 57a2022a 00000065
> nt!RtlpBreakWithStatusInstruction
> 8cd5277c 8292b96d 00000003 00000024 82fb7357 nt!KiBugCheckDebugBreak+0x1c
> 8cd52b40 828947eb 0000000a 00000024 00000002 nt!KeBugCheck2+0x68b
> 8cd52b40 82fb7357 0000000a 00000024 00000002 nt!KiTrap0E+0x2cf
> 8cd52be0 82fb7806 86e5eb10 86e5eb10 86e5ecc4
> storport!RaidUnitReleaseIrp+0x11
> 8cd52c1c 82fb7a65 8750eac0 856e9008 8559b0e8
> storport!RaUnitAsyncError+0x15e
> 8cd52c50 82fa91d9 8750eac0 8559b0a4 8cd3b884
> storport!RaidUnitCompleteRequest+0x101
> 8cd52c78 828b63b5 8559b0a4 8559b030 00000000
> storport!RaidpAdapterDpcRoutine+0x51
> 8cd52cd4 828b6218 8cd36120 8cd3b800 00000000 nt!KiExecuteAllDpcs+0xf9
> 8cd52d20 828b6038 00000000 0000000e 00000000 nt!KiRetireDpcList+0xd5
> 8cd52d24 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x38
>
>
> STACK_COMMAND: kb
> FOLLOWUP_IP:
> storport!RaidUnitReleaseIrp+11
> 82fb7357 8b7e24 mov edi,dword ptr [esi+24h]
>
> SYMBOL_STACK_INDEX: 4
> SYMBOL_NAME: storport!RaidUnitReleaseIrp+11
> FOLLOWUP_NAME: MachineOwner
> MODULE_NAME: storport
> IMAGE_NAME: storport.sys
> DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bc736
> FAILURE_BUCKET_ID: 0xD1_storport!RaidUnitReleaseIrp+11
> BUCKET_ID: 0xD1_storport!RaidUnitReleaseIrp+11
> Followup: MachineOwner
>
> How i need to debug this kind of issues?
>
> Thanks,
> Amogha
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
I can see that from the bug check. I wanted to know how to debug the error. As in this condition, the debugger doesn’t point to any of my driver code. Hence i wanted to know how to debug such conditions.
Thanks,
Amogha
Are you completing (StorportNotification RequestComplete) the Srb twice? Or
do you complete the Srb in HwStorBuildIo but returning the status (of the
HwStorBuildIo) as TRUE?
This is the typical case of double-completing Srb. Since completion of Srb
happens in Dpc you will not find your driver in stack!
Regards,
Gokul T V
On Mon, Mar 28, 2011 at 2:51 PM, wrote:
> I can see that from the bug check. I wanted to know how to debug the error.
> As in this condition, the debugger doesn’t point to any of my driver code.
> Hence i wanted to know how to debug such conditions.
>
> Thanks,
> Amogha
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Hi Gokul,
I checked the driver. I am not completing the srb twice anywhere in the code. In buildIO( ), for some Srb->Functions, i am completing the request and return false.
Thanks,
Amogha
If you pretty sure that there are no double completions, try with
checked-build version of storport.sys, I may give you some more information
w.r.t this BSOD.
Regards,
Gokul T V
On Mon, Mar 28, 2011 at 3:41 PM, wrote:
> Hi Gokul,
>
> I checked the driver. I am not completing the srb twice anywhere in the
> code. In buildIO( ), for some Srb->Functions, i am completing the request
> and return false.
>
> Thanks,
> Amogha
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Hi Gokul,
Can you please tell me the steps to enable check build for storport.sys ?
Thanks,
Amogha
Search the archives of this forum or google it. It has been discussed many
times in this forum w.r.t getting checked-build driver and viewing the
debug-prints/msgs of it.
Best Regards,
Gokul T V
On Mon, Mar 28, 2011 at 4:58 PM, wrote:
> Hi Gokul,
>
> Can you please tell me the steps to enable check build for storport.sys ?
>
> Thanks,
> Amogha
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
The most obvious thing to do is to connect WinDbg via a 1394 connection and do some honest debug before you come here and ask why your driver is failing and/or how to debug your driver. You have a BSOD, so what is the output of !analyze -v? Given you have done your homework and looked around this forum before simply posting a “why does my driver BSOD” you would know one of the first things we are going to request is the output of !analyze -v. So where is it?
Gary G. Little
----- Original Message -----
From: “amogha bv”
To: “Windows System Software Devs Interest List”
Sent: Monday, March 28, 2011 3:31:42 AM
Subject: [ntdev] Miniport driver.
Hi,
I am new to driver development. I have written a miniport driver which loads correctly.
When i try to run IO using IO meter/any application, the driver gives BSOD. These BSOD error code change every time, some time storport.sys or USBPORT.sys or classpnp.sys etc . It doesn’t show error in my driver code.
What is the wrong thing i am doing in my driver? How can i debug the driver?
Thanks,
Amogha
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Hi Gary,
I have put the log from !analyze -v command above in my message 3 of this post.
I have done a lot debugging and finally decided to ask in the forum as i was unable to find the issue.
Thanks,
Amogha
I have not tried myself but you could try
xxxxx@gmail.com wrote:
Hi Gokul,
I checked the driver. I am not completing the srb twice anywhere in the code. In buildIO( ), for some Srb->Functions, i am completing the request and return false.
Desk-checking is not enough to detect this kind of error. It’s very
easy to complete a request twice accidentally. You should add debug
tracing to your code that prints each SRB as you receive it, and as you
complete it. Then, you can look over the log to see if a single request
gets completed twice.
The key issue is that something you are doing is causing storport to do
dereference a null pointer.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Sarbojit Sarkar wrote:
OK…
As per the log your driver is trying to access pageable memory at
Dispatch level. Which is not allowed.
That is not a helpful analysis, nor is it a correct analysis. His
driver is triggering a null pointer dereference in storport, which is
not his driver.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I am apologies for that. 
It will be a great help for us(at least for me) if you can tell how you got
to know from given debug log that his driver is triggering a null pointer
deference?
On Mon, Mar 28, 2011 at 10:50 PM, Tim Roberts wrote:
> Sarbojit Sarkar wrote:
> > OK…
> > As per the log your driver is trying to access pageable memory at
> > Dispatch level. Which is not allowed.
>
> That is not a helpful analysis, nor is it a correct analysis. His
> driver is triggering a null pointer dereference in storport, which is
> not his driver.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
The original bugcheck contained this line:
Arg1: 00000024, memory referenced
That’s 9 DWORDs above zero. AFAIK, the first page of memory is never mapped, specifically to catch errors like this. So any memory address less than 4K will (usually) cause this bugcheck.
Phil
Philip D. Barila
I tried to enable debug messages from STORPORT.sys through windbg command ed nt!Kd_StorPort_Mask 0xFFFFFFFF.
Is this enough to enable or should i do something else. I am not getting debug messages from storport.sys. Please help
Amogha
Sarbojit Sarkar wrote:
It will be a great help for us(at least for me) if you can tell how
you got to know from given debug log that his driver is triggering a
null pointer deference?
Certainly. Let’s look at the register part of the dump (usually the
most interesting part to me):
ErrCode = 00000000
eax=86e5eb10 ebx=86e5eb10 ecx=86e5ebc8 edx=00000000 esi=00000000 edi=86e5ecc4
eip=82fb7357 esp=8cd52bd4 ebp=8cd52be0 iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
storport!RaidUnitReleaseIrp+0x11:
82fb7357 8b7e24 mov edi,dword ptr [esi+24h] ds:0023:00000024=???
It’s loading into edi a dword that is 24h bytes from the address in esi,
and esi is 0. That almost certainly means its trying to do a structure
reference like this:
abc = pStruct->Field;
where Field is 24h bytes into the structure, and pStruct is NULL.
I notice that the function name refers to releasing an IRP; a quick look
inside <wdm.h> shows me that the IoStatus field is 24h bytes into the
IRP structure. Now I’m speculating, of course, but it’s a reasonable
guess that someone has passed in a null PIRP somewhere, and this
function is trying to read the IoStatus block.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.</wdm.h>
Hi,
w.r.t above issue, when i run IO meter, it runs for around 160 IO/s and then crashes. And every time the crash occurs in different files some time storport.sys or usb.sys or nt.sys etc.
Amogha