开发者

memory read error in my DriverUnload callback,which causes BSOD,why?

开发者 https://www.devze.com 2023-03-04 03:11 出处:网络
I\'m following this example. Code in DriverEntry: UNICODE_STRING symLinkName; RtlInitUnicodeString(&symLinkName,L\"\\\\??\\\\HelloDDK\");

I'm following this example.

Code in DriverEntry:

UNICODE_STRING symLinkName;
RtlInitUnicodeString(&symLinkName,L"\\??\\HelloDDK");
pDevExt->ustrSymLinkName = symLinkName;

Code in DriverUnload:

VOID HelloDDKUnload (IN PDRIVER_OBJECT pDriverObject) 
{
    PDEVICE_OBJECT  pNextObj;
    KdPrint(("Enter DriverUnload\n"));
    pNextObj = pDriverObject->DeviceObject;
    while (pNextObj != NULL) 
    {
        PDEVICE_EXTENSION pDevExt = (PDEVICE_EXTENSION)
            pNextObj开发者_Go百科->DeviceExtension;

Output in windbg:

kd> ?? pDevExt->ustrSymLinkName
struct _UNICODE_STRING
 "--- memory read error at address 0xf89f7210 ---"
   +0x000 Length           : 0x18
   +0x002 MaximumLength    : 0x1a
   +0x004 Buffer           : 0xf89f7210  "--- memory read error at address 0xf89f7210 ---"

Anyone ever met this kind of problem?


I am guessing in DriverUnload, pDevExt->ustrSymLinkName points to a local variable belong to DriverEntry?


At the time DriverUnload is called there're no more created devices. Hence - it's obsolete to try to use DeviceObject and NextDevice members of the DRIVER_OBJECT structure.

What's surprising is that NextDevice isn't set to NULL, according to your debug output, but nevertheless it's just a technical note.

If you want to do a per-device cleanup you should rather do it in your dispatch routine in response to IRP_MJ_CLOSE.

UPD

The question author posted in the comments that iterating through the created devices in the driver unload routine is a common practice, and provided the reference article at the codeproject, with the appropriate source code.

After reading the article and the source code it became more clear.

Usually the driver "creates a device" (i.e. calls IoCreateDevice) in response to the OS request, which originates from a call to CreateFile (or similar). When the device handle is closed - driver receives the appropriate request and "destroys" the device (IoDeleteDevice). The OS will not unload the driver if there're open handles to its devices, hence within the driver uninitialization routine there are no created devices.

However the driver in the reference article doesn't follow this logic. It creates the device at the beginning, right in its initialization routine DriverEntry. This does not prevent the OS from unloading the driver, because there're no open references to this device, hence the driver really needs to do the device cleanup in its DriverUnload.

Alright, this makes sense now. Except, from my personal experience, it's not a common practice to work this way, but this is not forbidden nevertheless.

Now, regarding your problem. Maybe you just made a mistake in the loop? I mean:

while (pNextObj != NULL) {
    PDEVICE_EXTENSION pDevExt = (PDEVICE_EXTENSION) pNextObj->DeviceExtension;

    // ...

    pNextObj = pNextObj->NextDevice;

    // then delete the device using the Extension
    IoDeleteDevice( pDevExt->pDevice );
}

Are you sure you do the things in the same order? Means, you first get the pointer to the next device object, and then call IoDeleteDevice?

Please post the whole code of your DriverUnload if you still have the problem.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号