There is no guarantee whatsoever the driver binary will be reloaded every
time before FindAdapter is called. Even for a root-enumerated device, which
you probably have. For example, there is storport.sys bug, which leaves a
hanging device object every time a SCSI target disappears from under it. If
that happens, your binary will bever be unloaded until a reboot.
"cristalink" <> wrote in message
news:O7IE2L$...
> In my current design, DriverEntry allocates memory and stores the pointer
> in a global variable. VirtualHwStorFindAdapter then uses the global
> pointer. HwStorFreeAdapterResources frees the memory and zeroes the
> pointer. If VirtualHwStorFindAdapter is called again, it uses the null
> pointer, hence the crash.
>
> I cannot repro it. All I have is a small minidump with the call stack and
> registers. StorPort is almost undocumented, so I can't fix the issue
> without being able to repro it.
>
>> Are you saying that you haven't received
>> SRB_FUNCTION_PNP/StorRemoveDevice for it?
>
> I have the call stack only, so I cannot say whether StorRemoveDevice was
> called or not. But it shouldn't matter anyway. All I need is to repro the
> case.
>
>
> Nick
>
>
>
> "Alexander Grigoriev" <> wrote in message
> news:%23SqVqs%...
>> Are you saying that you haven't received
>> SRB_FUNCTION_PNP/StorRemoveDevice for it?
>>
>> I saw such restart if DO_POWER_PAGABLE flag was set in the PDO. If I
>> remember correctly.
>>
>> "cristalink" <> wrote in message
>> news:...
>>> Hello,
>>>
>>> I have a memory dump from Microsoft OCA that indicates that the system
>>> called MyDriver!VirtualHwStorFindAdapter() after
>>> MyDriver!HwStorFreeAdapterResources() in my virtual StorPort miniport.
>>> My driver passed Winqual tests before. I tried sleep, hibernation, and
>>> "devcon restart mydriver", but I couldn't reproduce the call sequence.
>>> How can I reproduce the issue? Under which circumstances StorPort
>>> "restarts" my device and calls VirtualHwStorFindAdapter() without
>>> unloading my driver first after HwStorFreeAdapterResources()?
>>>
>>> Thanks,
>>>
>>> Nick
>>>
>>> STACK_TEXT:
>>> f78ea97c b865dfee 89e5b3dc 8948b030 89e6c730
>>> MyDriver!VirtualHwStorFindAdapter+0x538
>>> f78ea9b0 b865a0b6 00e6c8a0 b865df6c 00000000
>>> storport!RaCallMiniportFindAdapter+0x7c
>>> f78ea9d4 b868abce 89e6c7e8 89b66700 00000000
>>> storport!RaidAdapterStartMiniport+0x5a
>>> f78ea9f4 b868ad64 e138cec8 89b666a8 b8668510
>>> storport!RaidAdapterStartDeviceIrp+0xb0
>>> f78eaa14 b868b24f 01e6c7e8 00000000 89b66760
>>> storport!RaidAdapterPnpIrp+0xee
>>> f78eaa30 80840153 89e6c730 89b666a8 f78eaab0
>>> storport!RaDriverPnpIrp+0x6d
>>> f78eaa44 80901c8f f78eaab0 8948b030 00000000 nt!IofCallDriver+0x45
>>> f78eaa70 808de957 89e6c730 f78eaa8c 00000000 nt!IopSynchronousCall+0xb8
>>> f78eaab4 808deac4 8948b030 89cdad58 00000001 nt!IopStartDevice+0x4d
>>> f78eaad0 808dea89 8948b030 8948b001 89cdad58
>>> nt!PipProcessStartPhase1+0x4e
>>> f78ead28 808bc4de 89444008 00000001 00000000
>>> nt!PipProcessDevNodeTree+0x1db
>>> f78ead58 80801be5 00000003 89f97660 808b711c nt!PiRestartDevice+0x80
>>> f78ead80 8082db10 00000000 00000000 89f97660
>>> nt!PipDeviceActionWorker+0x188
>>> f78eadac 8092083b 00000000 00000000 00000000 nt!ExpWorkerThread+0xeb
>>> f78eaddc 8083fe9f 8082da53 00000001 00000000
>>> nt!PspSystemThreadStartup+0x2e
>>> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>>>
>>
>>
>
|
Linear Mode
