uncached extension in miniport

Is uncached extension allocated in IdeHwControl (for StartChannel) valid when IdeHwControl for StopChannel is called? the following link says: "
The port driver automatically frees the uncached extension after it invokes IdeHwControl with the StopChannel control action."

http://msdn.microsoft.com/en-us/library/ms802104.aspx

But when I try to access the uncached extension in IdeHwControl (for StopChannel) I get a SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e) bugcheck.

Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 98b4dd27, The address that the exception occurred at
Arg3: 84d65970, Exception Record Address
Arg4: 84d6566c, Context Record Address

Looks like uncached extension gets freed before StopChannel is called.

!analyze -v

mm

xxxxx@yahoo.com wrote:

Is uncached extension allocated in IdeHwControl (for StartChannel) valid when IdeHwControl for StopChannel is called? the following link says: "
The port driver automatically frees the uncached extension after it invokes IdeHwControl with the StopChannel control action."

http://msdn.microsoft.com/en-us/library/ms802104.aspx

But when I try to access the uncached extension in IdeHwControl (for StopChannel) I get a SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e) bugcheck.

Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 98b4dd27, The address that the exception occurred at
Arg3: 84d65970, Exception Record Address
Arg4: 84d6566c, Context Record Address

Looks like uncached extension gets freed before StopChannel is called.

Hi MM, here is the output of !analyze -v. Thanks.

Probably caused by : mydriver.sys ( mydriver!SendVu+77 )

Followup: MachineOwner

nt!RtlpBreakWithStatusInstruction:
81ace464 cc int 3
0: kd> !analyze -v
ERROR: FindPlugIns 8007007b
*******************************************************************************
* *
* 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: c0000005, The exception code that was not handled
Arg2: 98b4dd27, The address that the exception occurred at
Arg3: 84d65970, Exception Record Address
Arg4: 84d6566c, Context Record Address

Debugging Details:

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

FAULTING_IP:
mydriver!SendVu+77 [y:\miniport\fphwdep.c @ 2647]
98b4dd27 8b420c mov eax,dword ptr [edx+0Ch]

EXCEPTION_RECORD: 84d65970 – (.exr 0xffffffff84d65970)
ExceptionAddress: 98b4dd27 (mydriver!SendVu+0x00000077)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 0000000c
Attempt to read from address 0000000c

CONTEXT: 84d6566c – (.cxr 0xffffffff84d6566c)
eax=86e8761c ebx=00000000 ecx=00000000 edx=00000000 esi=86e860e0 edi=86e860e0
eip=98b4dd27 esp=84d65a38 ebp=84d65a44 iopl=0 nv up ei ng nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010282
mydriver!SendVu+0x77:
98b4dd27 8b420c mov eax,dword ptr [edx+0Ch] ds:0023:0000000c=???
Resetting default scope

PROCESS_NAME: System

CURRENT_IRQL: 2

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

READ_ADDRESS: 0000000c

BUGCHECK_STR: 0x7E

DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE

LAST_CONTROL_TRANSFER: from 98b4e7df to 98b4dd27

STACK_TEXT:
84d65a44 98b4e7df 86e8736c 00000001 84d65a6c mydriver!SendVu+0x77 [y:\miniport\fphwdep.c @ 2647]
84d65a54 98b4bdcf 86e8736c 00000001 000007ff mydriver!HwCtrlChannelStop+0xf [y:\miniport\fphwdep.c @ 3681]
84d65a6c 825aa0b4 86e8736c 00000001 00000000 mydriver!MydriverChannelControl+0x3f [y:\miniport\mydriver.c @ 1082]
84d65a80 825b71c3 86e860e0 00000001 00000000 ataport!CallMiniPortChannelControl+0x1a
84d65a9c 825bae14 86e860e0 86e860e0 84d65ac0 ataport!ChannelStopMiniport+0x1d
84d65aac 825bae47 86e86028 00000000 86e860e0 ataport!ChannelStopDevice+0x12
84d65ac0 825aa1d7 86e86028 00000000 825b8106 ataport!ChannelRemoveDevice+0x15
84d65ad4 825b8166 86e860e0 00000000 87f1d518 ataport!CallRemoveDevice+0x2d
84d65af4 825b8b61 86e86028 9f248f48 9f248f48 ataport!GenPnpFdoRemoveDevice+0x60
84d65b08 81cf86be 86e86028 9f248f48 9f249000 ataport!IdePortDispatchPnp+0x25
84d65b2c 81ad1f8a 9f248fdc 84d65bcc 86e86028 nt!IovCallDriver+0x23f
84d65b40 81bc7856 86eb5638 86eb5638 86f0ae68 nt!IofCallDriver+0x1b
84d65b74 81c91cdf 86eb5638 84d65ba8 00000000 nt!IopSynchronousCall+0xce
84d65bd0 81ae0601 86eb5638 00000002 9c8c4e28 nt!IopRemoveDevice+0xd1
84d65bf8 81c8b227 9b404990 00000000 00000000 nt!PnpRemoveLockedDeviceNode+0x176
84d65c10 81c8b4d7 00000002 00000000 00000000 nt!PnpDeleteLockedDeviceNode+0x2b
84d65c44 81c8f2c0 83a9c578 9c8c4e28 00000002 nt!PnpDeleteLockedDeviceNodes+0x4c
84d65d04 81b7ae17 84d65d34 00000000 9f47a460 nt!PnpProcessQueryRemoveAndEject+0x8cf
84d65d1c 81ba63c0 00000000 81b1813c 83af02d8 nt!PnpProcessTargetDeviceEvent+0x38
84d65d44 81a4e445 956983c8 00000000 83af02d8 nt!PnpDeviceEventWorker+0x201
84d65d7c 81bebb18 956983c8 8b6ff315 00000000 nt!ExpWorkerThread+0xfd
84d65dc0 81a44a2e 81a4e348 00000001 00000000 nt!PspSystemThreadStartup+0x9d
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

FOLLOWUP_IP:
mydriver!SendVu+77 [y:\miniport\fphwdep.c @ 2647]
98b4dd27 8b420c mov eax,dword ptr [edx+0Ch]

FAULTING_SOURCE_CODE:
2643: Irb = &(pFlashChannel->PrivateIrb);
2644: pIrbExt = (PDEN_IRB_EXTENSION)(Irb->IrbExtension);
2645: /* we will issue a VU command
2646: */

2647: pCmd = (PMY_CMD)&(pIrbExt->pAdjustedCmdTbl->c.cmd);
2648: pCmd->Opcode = MY_VU_CMD;
2649: pCmd->Parameters = 0;
2650:
2651:
2652: pIrbExt->NextState = VuResults;

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: mydriver!SendVu+77

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: mydriver

IMAGE_NAME: mydriver.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 49d3b6ae

STACK_COMMAND: .cxr 0xffffffff84d6566c ; kb

FAILURE_BUCKET_ID: 0x7E_VRF_mydriver!SendVu+77

BUCKET_ID: 0x7E_VRF_mydriver!SendVu+77

Followup: MachineOwner

IrbExtension was allocated using AtaPortGetUncachedExtension in StartChannel. And was being used before StopChannel also.

source code

mm

xxxxx@yahoo.com wrote:

IrbExtension was allocated using AtaPortGetUncachedExtension in StartChannel. And was being used before StopChannel also.

xxxxx@yahoo.com wrote:

Hi MM, here is the output of !analyze -v. Thanks.

Probably caused by : mydriver.sys ( mydriver!SendVu+77 )

CONTEXT: 84d6566c – (.cxr 0xffffffff84d6566c)
eax=86e8761c ebx=00000000 ecx=00000000 edx=00000000 esi=86e860e0 edi=86e860e0
eip=98b4dd27 esp=84d65a38 ebp=84d65a44 iopl=0 nv up ei ng nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010282
mydriver!SendVu+0x77:
98b4dd27 8b420c mov eax,dword ptr [edx+0Ch] ds:0023:0000000c=???
Resetting default scope

So, you’re trying to dereference a null pointer.

FOLLOWUP_IP:
mydriver!SendVu+77 [y:\miniport\fphwdep.c @ 2647]
98b4dd27 8b420c mov eax,dword ptr [edx+0Ch]

FAULTING_SOURCE_CODE:
2643: Irb = &(pFlashChannel->PrivateIrb);
2644: pIrbExt = (PDEN_IRB_EXTENSION)(Irb->IrbExtension);
2645: /* we will issue a VU command
2646: */

> 2647: pCmd = (PMY_CMD)&(pIrbExt->pAdjustedCmdTbl->c.cmd);
>
2648: pCmd->Opcode = MY_VU_CMD;
2649: pCmd->Parameters = 0;
2650:
2651:
2652: pIrbExt->NextState = VuResults;

So, either pIrbExt or pIrbExt->pAdjustedCmdTbl was NULL. You don’t
check for either here, so you get what you deserve. I will note that
this arrived as part of a “remove device” request. Should you expect
both of these to have valid values? What are you trying to send to your
device during removal processing?


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Hi Tim, the pointers are non-NULL (I checked them in the debugger). They were allocated by my driver and ataport driver is supposed to free them after IdeHwControl. And I was expecting that after this routine is completed. I’m sending a vendor unique command to the device when it is being asked to stop before actually stopping the device.

I suspect that Ataport driver has already freed this memory as specified (though not precisely) by this link:

http://msdn.microsoft.com/en-us/library/ms802104.aspx

“The port driver automatically frees the uncached extension after it invokes IdeHwControl with the StopChannel control action.”

All the above code (and the BSOD) is happening inside the IdeHwControl (StopChannel) routine.

xxxxx@yahoo.com wrote:

Hi Tim, the pointers are non-NULL (I checked them in the debugger). They were allocated by my driver and ataport driver is supposed to free them after IdeHwControl. And I was expecting that after this routine is completed.

Well, I don’t mean to call you a liar, but you are wrong. And given
that the code is just taking the address of the second pointer, I will
hereby assert that pIrbExt was NULL when that statement executed.

I suspect that Ataport driver has already freed this memory as specified (though not precisely) by this link:

http://msdn.microsoft.com/en-us/library/ms802104.aspx

“The port driver automatically frees the uncached extension after it invokes IdeHwControl with the StopChannel control action.”

All the above code (and the BSOD) is happening inside the IdeHwControl (StopChannel) routine.

But that says “AFTER it invokes”. I don’t know the ATA miniport model.
Do you get called once at “query remove” time, and again at “remove”
time? Is it possible this is happening twice?


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

+1

One more time:

  1. source code - the whole function(s); don’t omit the parts that you’re sure are fine

  2. I don’t know what you did with the debugger to conclude that ‘the’ pointers or non-null, and as
    usual, you won’t tell us. If I were you, I would do what Tim suggested and put some error checking
    around those pointers, and I think you’ll be surprised. Either way, it will be the easiest way to
    ensure that we are all talking about the same pointers, et. c.

  3. Please, please, please - stop telling us what the problem isn’t without first telling us what
    you did and providing what we ask for. Now, you may very well be right (though not in this case),
    but until you present the necessary information, there’s no way that we can help figure out what’s
    what.

mm

Tim Roberts wrote:

xxxxx@yahoo.com wrote:
> Hi Tim, the pointers are non-NULL (I checked them in the debugger). They were allocated by my driver and ataport driver is supposed to free them after IdeHwControl. And I was expecting that after this routine is completed.

Well, I don’t mean to call you a liar, but you are wrong. And given
that the code is just taking the address of the second pointer, I will
hereby assert that pIrbExt was NULL when that statement executed.

> I suspect that Ataport driver has already freed this memory as specified (though not precisely) by this link:
>
> http://msdn.microsoft.com/en-us/library/ms802104.aspx
>
> “The port driver automatically frees the uncached extension after it invokes IdeHwControl with the StopChannel control action.”
>
> All the above code (and the BSOD) is happening inside the IdeHwControl (StopChannel) routine.
>

But that says “AFTER it invokes”. I don’t know the ATA miniport model.
Do you get called once at “query remove” time, and again at “remove”
time? Is it possible this is happening twice?

Thank you MM and Tim. I found an alternative way to achieve what I was trying to do. Sorry posting the source code was not possible for me. Thanks again.