IRP_MN_START_DEVICE getting NULL resources in rebalance test

A few PNP tests are failing for my PCI UART device. I only supply my
own .inf and expect Windows to take care of driving the device with
serenum.sys / serial.sys.

Relevant .inf section:

[ComPort_inst1.RegHW]
HKR,Child0000,HardwareID,*PNP0501
HKR,Child0000,VaryingResourceMap,1,00, 00,00,00,00, 08,00,00,00
HKR,Child0000,ResourceMap,1,02

Full file at:
https://github.com/virtio-win/kvm-guest-drivers-windows/blob/master/pciserial/qemupciserial.inf

The first IRP_MN_START_DEVICE received after the test starts is fine:

Irp is active with 3 stacks 2 is current (= 0xffffd8843744cf28)
No Mdl: No System Buffer: Thread ffff9d88eb634040: Irp stack trace.
cmd flg cl Device File Completion-Context
[N/A(0), N/A(0)]
0 10 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[IRP_MJ_PNP(1b), IRP_MN_START_DEVICE(0)]
0 e0 ffff9d88eb6f3070 00000000
fffff808443c1200-ffffc800a30c8628 Success Error Cancel
\Driver\Serial serenum!SerenumSyncCompletion
Args: ffff88046d5c3690 ffff88046d6f8db0 00000000 00000000
[IRP_MJ_PNP(1b), IRP_MN_START_DEVICE(0)]
0 e0 ffff9d88eb6f3d60 00000000
fffff80200f73088-ffff9d88ebc27400 Success Error Cancel
\Driver\Serenum nt!PnpDeviceCompletionRoutine
Args: ffff88046d5c3690 ffff88046d6f8db0 00000000 00000000

The second one (presumably second iteration of the test) looks the
same but both args are NULL:

Irp is active with 3 stacks 2 is current (= 0xffffd884373c6f28)
No Mdl: No System Buffer: Thread ffff9d88ebef2040: Irp stack trace.
cmd flg cl Device File Completion-Context
[N/A(0), N/A(0)]
0 10 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[IRP_MJ_PNP(1b), IRP_MN_START_DEVICE(0)]
0 e0 ffff9d88eb6f3070 00000000
fffff808443c1200-ffffc800a3662628 Success Error Cancel
\Driver\Serial serenum!SerenumSyncCompletion
Args: 00000000 00000000 00000000 00000000
[IRP_MJ_PNP(1b), IRP_MN_START_DEVICE(0)]
0 e0 ffff9d88eb6f3d60 00000000
fffff80200f73088-ffff9d88e9e95880 Success Error Cancel
\Driver\Serenum nt!PnpDeviceCompletionRoutine
Args: 00000000 00000000 00000000 00000000

Why would this be happening? I don’t see any
IRP_MN_FILTER_RESOURCE_REQUIREMENTS or
IRP_MN_QUERY_RESOURCE_REQUIREMENTS in serial!SerialPnpDispatch. The
IRP sequence processed by this function looks like this:

IRP_MN_QUERY_CAPABILITIES
IRP_MN_QUERY_CAPABILITIES
IRP_MN_QUERY_CAPABILITIES
IRP_MN_QUERY_STOP_DEVICE
IRP_MN_QUERY_INTERFACE
IRP_MN_QUERY_INTERFACE
IRP_MN_STOP_DEVICE
IRP_MN_START_DEVICE <== this one is fine
IRP_MN_QUERY_STOP_DEVICE
IRP_MN_STOP_DEVICE
IRP_MN_START_DEVICE <== this one gets NULL resources
IRP_MN_QUERY_DEVICE_RELATIONS
IRP_MN_SURPRISE_REMOVAL
IRP_MN_REMOVE_DEVICE
IRP_MN_QUERY_CAPABILITIES

Thanks!
Ladi

There’s a couple of ways I can try to move forward with this but none
of them looks very appealing.

  1. It can be a bug in the device. Even more so since it’s implemented
    in software (part of a virtualization stack). I can try to find
    another PCI UART, run the same test, and either eliminate the device
    bug theory or see what’s different using a bus analyzer of some sort.

  2. It can be a bug in Windows. The documentation for
    IRP_MN_START_DEVICE does not talk about the arguments being NULL. “The
    Parameters.StartDevice.AllocatedResources member of … points to a
    CM_RESOURCE_LIST describing the hardware resources”. Maybe it’s
    customary to encode empty lists with NULL? I can continue reverse
    engineering Windows to see what makes it send this IRP.

  3. It can be a bug in serenum.sys / serial.sys. I can try building the
    serial WDF sample driver and make it drive my device instead of the
    inbox one. Having source code would make debugging a little easier and
    maybe something will pop out. And if the test passes and I won’t be
    able to figure out why, I can at least WHQL and ship the sample as a
    last resort.

Any and all comments and tips would be appreciated.

Thanks!
Ladi

On Wed, May 3, 2017 at 4:59 PM, Ladi Prosek wrote:
> A few PNP tests are failing for my PCI UART device. I only supply my
> own .inf and expect Windows to take care of driving the device with
> serenum.sys / serial.sys.
>
> Relevant .inf section:
>
> [ComPort_inst1.RegHW]
> HKR,Child0000,HardwareID,*PNP0501
> HKR,Child0000,VaryingResourceMap,1,00, 00,00,00,00, 08,00,00,00
> HKR,Child0000,ResourceMap,1,02
>
> Full file at:
> https://github.com/virtio-win/kvm-guest-drivers-windows/blob/master/pciserial/qemupciserial.inf
>
>
> The first IRP_MN_START_DEVICE received after the test starts is fine:
>
> Irp is active with 3 stacks 2 is current (= 0xffffd8843744cf28)
> No Mdl: No System Buffer: Thread ffff9d88eb634040: Irp stack trace.
> cmd flg cl Device File Completion-Context
> [N/A(0), N/A(0)]
> 0 10 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
>>[IRP_MJ_PNP(1b), IRP_MN_START_DEVICE(0)]
> 0 e0 ffff9d88eb6f3070 00000000
> fffff808443c1200-ffffc800a30c8628 Success Error Cancel
> \Driver\Serial serenum!SerenumSyncCompletion
> Args: ffff88046d5c3690 ffff88046d6f8db0 00000000 00000000
> [IRP_MJ_PNP(1b), IRP_MN_START_DEVICE(0)]
> 0 e0 ffff9d88eb6f3d60 00000000
> fffff80200f73088-ffff9d88ebc27400 Success Error Cancel
> \Driver\Serenum nt!PnpDeviceCompletionRoutine
> Args: ffff88046d5c3690 ffff88046d6f8db0 00000000 00000000
>
>
> The second one (presumably second iteration of the test) looks the
> same but both args are NULL:
>
> Irp is active with 3 stacks 2 is current (= 0xffffd884373c6f28)
> No Mdl: No System Buffer: Thread ffff9d88ebef2040: Irp stack trace.
> cmd flg cl Device File Completion-Context
> [N/A(0), N/A(0)]
> 0 10 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
>>[IRP_MJ_PNP(1b), IRP_MN_START_DEVICE(0)]
> 0 e0 ffff9d88eb6f3070 00000000
> fffff808443c1200-ffffc800a3662628 Success Error Cancel
> \Driver\Serial serenum!SerenumSyncCompletion
> Args: 00000000 00000000 00000000 00000000
> [IRP_MJ_PNP(1b), IRP_MN_START_DEVICE(0)]
> 0 e0 ffff9d88eb6f3d60 00000000
> fffff80200f73088-ffff9d88e9e95880 Success Error Cancel
> \Driver\Serenum nt!PnpDeviceCompletionRoutine
> Args: 00000000 00000000 00000000 00000000
>
>
> Why would this be happening? I don’t see any
> IRP_MN_FILTER_RESOURCE_REQUIREMENTS or
> IRP_MN_QUERY_RESOURCE_REQUIREMENTS in serial!SerialPnpDispatch. The
> IRP sequence processed by this function looks like this:
>
> IRP_MN_QUERY_CAPABILITIES
> IRP_MN_QUERY_CAPABILITIES
> IRP_MN_QUERY_CAPABILITIES
> IRP_MN_QUERY_STOP_DEVICE
> IRP_MN_QUERY_INTERFACE
> IRP_MN_QUERY_INTERFACE
> IRP_MN_STOP_DEVICE
> IRP_MN_START_DEVICE <== this one is fine
> IRP_MN_QUERY_STOP_DEVICE
> IRP_MN_STOP_DEVICE
> IRP_MN_START_DEVICE <== this one gets NULL resources
> IRP_MN_QUERY_DEVICE_RELATIONS
> IRP_MN_SURPRISE_REMOVAL
> IRP_MN_REMOVE_DEVICE
> IRP_MN_QUERY_CAPABILITIES
>
> Thanks!
> Ladi

I would focus your energy on 1 as the resource list is built from what the bus driver reports, not the fdo or filter on the stack

Bent from my phone


From: xxxxx@lists.osr.com on behalf of Ladi Prosek
Sent: Wednesday, May 3, 2017 10:18:06 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] IRP_MN_START_DEVICE getting NULL resources in rebalance test

There’s a couple of ways I can try to move forward with this but none
of them looks very appealing.

1) It can be a bug in the device. Even more so since it’s implemented
in software (part of a virtualization stack). I can try to find
another PCI UART, run the same test, and either eliminate the device
bug theory or see what’s different using a bus analyzer of some sort.

2) It can be a bug in Windows. The documentation for
IRP_MN_START_DEVICE does not talk about the arguments being NULL. “The
Parameters.StartDevice.AllocatedResources member of … points to a
CM_RESOURCE_LIST describing the hardware resources”. Maybe it’s
customary to encode empty lists with NULL? I can continue reverse
engineering Windows to see what makes it send this IRP.

3) It can be a bug in serenum.sys / serial.sys. I can try building the
serial WDF sample driver and make it drive my device instead of the
inbox one. Having source code would make debugging a little easier and
maybe something will pop out. And if the test passes and I won’t be
able to figure out why, I can at least WHQL and ship the sample as a
last resort.

Any and all comments and tips would be appreciated.

Thanks!
Ladi

On Wed, May 3, 2017 at 4:59 PM, Ladi Prosek wrote:
> A few PNP tests are failing for my PCI UART device. I only supply my
> own .inf and expect Windows to take care of driving the device with
> serenum.sys / serial.sys.
>
> Relevant .inf section:
>
> [ComPort_inst1.RegHW]
> HKR,Child0000,HardwareID,*PNP0501
> HKR,Child0000,VaryingResourceMap,1,00, 00,00,00,00, 08,00,00,00
> HKR,Child0000,ResourceMap,1,02
>
> Full file at:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fvirtio-win%2Fkvm-guest-drivers-windows%2Fblob%2Fmaster%2Fpciserial%2Fqemupciserial.inf&amp;data=02|01|Doron.Holan%40microsoft.com|66eb9a9f6fc0475e803a08d492acfc00|72f988bf86f141af91ab2d7cd011db47|1|0|636294719046048705&amp;sdata=gVKYh%2FPka3KNhCa20dmyK2USsxN2kKRHhy1KkRal3wU%3D&amp;reserved=0
>
>
> The first IRP_MN_START_DEVICE received after the test starts is fine:
>
> Irp is active with 3 stacks 2 is current (= 0xffffd8843744cf28)
> No Mdl: No System Buffer: Thread ffff9d88eb634040: Irp stack trace.
> cmd flg cl Device File Completion-Context
> [N/A(0), N/A(0)]
> 0 10 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
>>[IRP_MJ_PNP(1b), IRP_MN_START_DEVICE(0)]
> 0 e0 ffff9d88eb6f3070 00000000
> fffff808443c1200-ffffc800a30c8628 Success Error Cancel
> \Driver\Serial serenum!SerenumSyncCompletion
> Args: ffff88046d5c3690 ffff88046d6f8db0 00000000 00000000
> [IRP_MJ_PNP(1b), IRP_MN_START_DEVICE(0)]
> 0 e0 ffff9d88eb6f3d60 00000000
> fffff80200f73088-ffff9d88ebc27400 Success Error Cancel
> \Driver\Serenum nt!PnpDeviceCompletionRoutine
> Args: ffff88046d5c3690 ffff88046d6f8db0 00000000 00000000
>
>
> The second one (presumably second iteration of the test) looks the
> same but both args are NULL:
>
> Irp is active with 3 stacks 2 is current (= 0xffffd884373c6f28)
> No Mdl: No System Buffer: Thread ffff9d88ebef2040: Irp stack trace.
> cmd flg cl Device File Completion-Context
> [N/A(0), N/A(0)]
> 0 10 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
>>[IRP_MJ_PNP(1b), IRP_MN_START_DEVICE(0)]
> 0 e0 ffff9d88eb6f3070 00000000
> fffff808443c1200-ffffc800a3662628 Success Error Cancel
> \Driver\Serial serenum!SerenumSyncCompletion
> Args: 00000000 00000000 00000000 00000000
> [IRP_MJ_PNP(1b), IRP_MN_START_DEVICE(0)]
> 0 e0 ffff9d88eb6f3d60 00000000
> fffff80200f73088-ffff9d88e9e95880 Success Error Cancel
> \Driver\Serenum nt!PnpDeviceCompletionRoutine
> Args: 00000000 00000000 00000000 00000000
>
>
> Why would this be happening? I don’t see any
> IRP_MN_FILTER_RESOURCE_REQUIREMENTS or
> IRP_MN_QUERY_RESOURCE_REQUIREMENTS in serial!SerialPnpDispatch. The
> IRP sequence processed by this function looks like this:
>
> IRP_MN_QUERY_CAPABILITIES
> IRP_MN_QUERY_CAPABILITIES
> IRP_MN_QUERY_CAPABILITIES
> IRP_MN_QUERY_STOP_DEVICE
> IRP_MN_QUERY_INTERFACE
> IRP_MN_QUERY_INTERFACE
> IRP_MN_STOP_DEVICE
> IRP_MN_START_DEVICE <== this one is fine
> IRP_MN_QUERY_STOP_DEVICE
> IRP_MN_STOP_DEVICE
> IRP_MN_START_DEVICE <== this one gets NULL resources
> IRP_MN_QUERY_DEVICE_RELATIONS
> IRP_MN_SURPRISE_REMOVAL
> IRP_MN_REMOVE_DEVICE
> IRP_MN_QUERY_CAPABILITIES
>
> Thanks!
> Ladi


NTDEV is sponsored by OSR

Visit the list online at: https:

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

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

Ladi,

Did you check event log? PnP manager logs a lot to ETW, it might shed some light on the issue. And if not, it worth to BP on nt!PnpReallocateResources function. It has a block that calls PnpBuildCmResourceLists followed by call to PnpStartDeviceNode (actually sends MN_START).

Nothing helpful in the event log unfortunately. Thank you for the
pointers, I’ll look into it.

Playing with the VaryingResourceMap and ResourceMap registry keys in
the .inf file, it’s actually pretty easy to get mf.sys to trigger a
verifier violation on unload.

DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught. This is
because the driver was specified in the registry as being suspect (by the
administrator) and the kernel has enabled substantial checking of this driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA will
be among the most commonly seen crashes.
Arguments:
Arg1: 0000000000000062, A driver has forgotten to free its pool
allocations prior to unloading.
Arg2: ffffd18387465af0, name of the driver having the issue.
Arg3: ffffd18387479d30, verifier internal structure with driver information.
Arg4: 0000000000000004, total # of (paged+nonpaged) allocations that
weren’t freed.
Type !verifier 3 drivername.sys for info on the allocations
that were leaked that caused the bugcheck.

BUILD_VERSION_STRING: 14393.693.amd64fre.rs1_release.161220-1747

IMAGE_NAME: mf.sys

7: kd> !verifier 3 mf.sys

Current paged pool allocations 0x65 for 00002734 bytes
Peak paged pool allocations 0x76 for 0000F1E6 bytes
Current nonpaged pool allocations 0x3f8 for 0006E6F0 bytes
Peak nonpaged pool allocations 0x407 for 0006F2E0 bytes

Driver Verification List

nt!_VF_TARGET_DRIVER 0xffffd1838712f490: mf.sys (Loaded and Unloaded)

Pool Allocation Statistics: ( NonPagedPool / PagedPool )

Current Pool Allocations: ( 0x00000000 / 0x00000004 )
Current Pool Bytes: ( 0x00000000 / 0x00000040 )
Peak Pool Allocations: ( 0x00000007 / 0x00000011 )
Peak Pool Bytes: ( 0x00000380 / 0x00003848 )
Contiguous Memory Bytes: 0x00000000
Peak Contiguous Memory Bytes: 0x00000000

Pool Allocations:

Address Length Tag Caller Address


0xffff9604a6aa4fe0 0x00000014 MfVM 0xfffff80375737814 mf+0x7814
0xffff9604a6ae8fe0 0x00000014 Mf 0xfffff8037573a2c4 mf+0xa2c4
0xffff9604a6a92ff0 0x00000008 MfRM 0xfffff803757379c5 mf+0x79c5
0xffff9604a6aecff0 0x00000010 Mf 0xfffff80375737b99 mf+0x7b99

Contiguous allocations are not displayed with public symbols.

7: kd> lm vm mf
Browse full module list
start end module name
fffff80375730000 fffff80375741000 mf (no symbols)
Loaded symbol image file: mf.sys
Image path: \SystemRoot\System32\drivers\mf.sys
Image name: mf.sys
Browse all global symbols functions data
Timestamp: Sat Jul 16 04:21:02 2016 (57899A0E)
CheckSum: 0001579F
ImageSize: 00011000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4

Based on Doron’s comment that it’s the bus driver that has direct
impact on the resource list, I think I’ll spend some time
disassembling and tracing mf.sys. Where there’s one bug, there may be
another :wink:

Thanks!

On Thu, May 4, 2017 at 1:28 PM, wrote:
> Ladi,
>
> Did you check event log? PnP manager logs a lot to ETW, it might shed some light on the issue. And if not, it worth to BP on nt!PnpReallocateResources function. It has a block that calls PnpBuildCmResourceLists followed by call to PnpStartDeviceNode (actually sends MN_START).
>
> —
> 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 key piece of information missing from your first message is that you use MF.sys as your bus driver.

It’s possible that rebalancing just doesn’t work with MF.sys, or PNP manager cuts a corner and doesn’t query the updated resource requirements/filtered resources from MF.sys and thus finds that it cannot allocate them.

> Full file at:
https://github.com/virtio-win/kvm-guest-drivers-windows/blob/master/pciserial/qem
upciserial.inf

Do you run this on a kvm guest? It may be artifact of kvm, try a physical machine.

– pa

On Thu, May 4, 2017 at 4:44 PM, wrote:
> The key piece of information missing from your first message is that you use MF.sys as your bus driver.

Ah, sorry, I thought that was implied by the use of VaryingResourceMap
/ ResourceMap. The device exists in several flavors, a 1 COM port
device, 2 port device and 4 port per device. My trouble is with the 1x
so I guess I may be able to make this work without mf.

> It’s possible that rebalancing just doesn’t work with MF.sys, or PNP manager cuts a corner and doesn’t query the updated resource requirements/filtered resources from MF.sys and thus finds that it cannot allocate them.

Got it. I’ll see if I can confirm this. I realized that there are no
public symbols for mf.sys moments after sending my previous message so
it may take more time to drill into this.

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

On Thu, May 4, 2017 at 5:22 PM, wrote:
>> Full file at:
> https://github.com/virtio-win/kvm-guest-drivers-windows/blob/master/pciserial/qem
> upciserial.inf
>
> Do you run this on a kvm guest? It may be artifact of kvm, try a physical machine.

Yes, I run this on a KVM/QEMU guest and am only interested in this
setup. I don’t think that this device exists in the physical world.

> – pa
>
>
> —
> 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:>

On Thu, May 4, 2017 at 5:40 PM, Ladi Prosek wrote:
> On Thu, May 4, 2017 at 4:44 PM, wrote:
>> The key piece of information missing from your first message is that you use MF.sys as your bus driver.
>
> Ah, sorry, I thought that was implied by the use of VaryingResourceMap
> / ResourceMap. The device exists in several flavors, a 1 COM port
> device, 2 port device and 4 port per device. My trouble is with the 1x
> so I guess I may be able to make this work without mf.
>
>> It’s possible that rebalancing just doesn’t work with MF.sys, or PNP manager cuts a corner and doesn’t query the updated resource requirements/filtered resources from MF.sys and thus finds that it cannot allocate them.
>
> Got it. I’ll see if I can confirm this. I realized that there are no
> public symbols for mf.sys moments after sending my previous message so
> it may take more time to drill into this.

Ok, so I fixed up an older .inf which doesn’t use mf.sys and it passes
the test. The downside is that I can’t drive multi-port devices (one
combined I/O bar, one shared interrupt), but luckily they are not
supported yet so I should be good for the upcoming release. The new
.inf looks like this:

https://github.com/virtio-win/kvm-guest-drivers-windows/blob/master/pciserial/rhel/qemupciserial.inf

Doron, is there anything I can do to help get MF fixed? Would you be
interested in a dump with the verifier BSOD I mentioned earlier? I can
also open an official support ticket if it helps.

Thank you to everyone who chimed in!
Ladi

You should open a support incident if you want to try to have this fixed.

Bent from my phone


From: xxxxx@lists.osr.com on behalf of Ladi Prosek
Sent: Wednesday, May 10, 2017 12:24:46 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] IRP_MN_START_DEVICE getting NULL resources in rebalance test

On Thu, May 4, 2017 at 5:40 PM, Ladi Prosek wrote:
> On Thu, May 4, 2017 at 4:44 PM, wrote:
>> The key piece of information missing from your first message is that you use MF.sys as your bus driver.
>
> Ah, sorry, I thought that was implied by the use of VaryingResourceMap
> / ResourceMap. The device exists in several flavors, a 1 COM port
> device, 2 port device and 4 port per device. My trouble is with the 1x
> so I guess I may be able to make this work without mf.
>
>> It’s possible that rebalancing just doesn’t work with MF.sys, or PNP manager cuts a corner and doesn’t query the updated resource requirements/filtered resources from MF.sys and thus finds that it cannot allocate them.
>
> Got it. I’ll see if I can confirm this. I realized that there are no
> public symbols for mf.sys moments after sending my previous message so
> it may take more time to drill into this.

Ok, so I fixed up an older .inf which doesn’t use mf.sys and it passes
the test. The downside is that I can’t drive multi-port devices (one
combined I/O bar, one shared interrupt), but luckily they are not
supported yet so I should be good for the upcoming release. The new
.inf looks like this:

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fvirtio-win%2Fkvm-guest-drivers-windows%2Fblob%2Fmaster%2Fpciserial%2Frhel%2Fqemupciserial.inf&amp;data=02|01|Doron.Holan%40microsoft.com|957a3b84e9a64c3acda808d49775aadc|72f988bf86f141af91ab2d7cd011db47|1|0|636299979014258605&amp;sdata=HWtZXf2wBtjFaapDk%2BragSp67xw5qtxcHnGZg7jLqfw%3D&amp;reserved=0

Doron, is there anything I can do to help get MF fixed? Would you be
interested in a dump with the verifier BSOD I mentioned earlier? I can
also open an official support ticket if it helps.

Thank you to everyone who chimed in!
Ladi


NTDEV is sponsored by OSR

Visit the list online at: https:

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

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