How to isolate UMDF driver from app memory corruption

I have a customer binary I must use, which is corrupting the malloc arena practically out of the box. That said, the binary "works" with a kmdf driver. The problem comes with the UMDF driver (adopted because of signing catch 22s). When WdfCompleteRequestWithInformation is called, the WUDFHost process crashes with memory corruption error (0xc0000374).

My impression is UMDF is more prone to this than KMDF. Is there any way to isolate myself from the misbehavining app?

BTW, when rebuilt with various bugs fixed the app works fine, but the customer wants to stick with the old (VC++ 2005) binary. I presume the issue is with changes in the API in the last 20 years or so.

Do you mean, you have a customer binary LIBRARY that you have to link into your UMDF driver? I would never ship a driver with a known bad library. That's just poor engineering.

It's a GOOD thing that the UMDF process crashes; if you build the library into a KMDF driver, it's likely damaging system data structures without being detected, and that's worse..

Your post makes exactly zero sense. None at all.

You cannot call “malloc” in kernel mode, so if this library or whatever “binary” it is that you link to, is corrupting something… I don’t know what to say.

I think you need to get a better idea of what’s exactly going on, and what’s going wrong, before you do anything else.

The driver is a User Mode Driver Framework dll, not kernel mode. The issue would not exist on a KMDF driver, which is currently implemented. Difficulty getting the kernel driver signed has made a user mode driver necessary.

User Mode Driver Framework runs the driver as a service under WUDFHost.exe in either "its own process" or a "Shared Process". This seems to be controlled by the ServiceType value.

User Mode Driver Framework requires the use of standard user space memory APIs, not ExAllocatePoolx.

The driver (service dll) seems to be executed in the same process space as the application, which allows the application to corrupt the memory arena shared between the serivce and the app, which in turn crashes the driver.

I think I will be able to isolate the service (driver) by having it run in a shared process, since the buffers will need to be marhsalled.

I was looking for help and experience in how to do this.

The driver (service.dll) seems to be executed in the same process as the application, ...

No. A UMDF driver is always isolated in a different process, running in an application called WUDFHost.exe. The choice you mentioned is whether your driver is in its OWN WUDFHost.exe, or in a process shared with other UMDF DLLs.

... which allows the application to corrupt the memory arena shared between the serivce and the app, ..

Nope. It's a separate address space. Buffers are always marshalled. Application misbehavior cannot corrupt the UMDF process. Now, it's certainly possible for an application to exploiit a driver bug that trashed the UMDF process, but not directly.

I think you still have a fair amount of debugging to do. Have you turned on the UMDF Driver Verifier? Have you captured the crash in a debugger?

Have you turned on the UMDF Driver Verifier? Have you captured the crash in a debugger?


The problem comes in WdfUsbRequestCOmpleteWithInformation, and is reported as memory corruption (0xc0000374)

At that point the only memory available to corrupt is in the buffers (the called api is DeviceIoControl).

I have driver verifier on and app verifiier, and its clean. I'm debugging in windows 10 so the varifier can be relied upon. App Verifier calls out the app at NtDll.dll load.
When I run the app in compat mode for Windows Vista, everything is clean, including the app and driver.

I'm trying to get the customer to agree to a new binary (alreadfy built). Its an uphill battle.

You have a bug processing the io request, and your bug is exposed by the ‘customer app’, which may also have bugs.

Buggy io request processing is massively common.

Your driver is corrupting memory in your driver’s process space.

The problem comes in WdfUsbRequestCOmpleteWithInformation

There is no such API. Did you mean WdfRequestCompleteWithInformation? One of the subtle ways this can fail is if the value you passed for information is whacked out. Remember that, for a METHOD_BUFFERED ioctl, the system has to copy that much data back over to the caller.

My apologies. Obviously, I was reading too quickly. Ugh… I’ll try to be a little more careful.