Troubleshoot KMDF Driver Crash

NTDEV
1

Hi,

I have KMDF driver. One of my customer is facing crash while using the drive. Unfortunately the crash is not reproducible in my system, but it is reproducible in customer system.
I provided debug build of my driver along with IFR logging enabled with log messages in my driver. When i got the crash dump from the customer, i could see that faulting source line of my driver
which is pointing to SysCopyMemory function.

The function is like below
SysCopyMemory(ReceiveBuffer, dataToCopy, dataLength)

The ReceiveBuffer is valid buffer, which i can confirm and it has enough size to hold data which is copied in SysCopyMemory.

The driver is built with following configuration
**Windows OS: Windows 10
Windows SDK version: 10.0.19041.0
**
Visual studio version used to build the driver : VS2019

When i tried to get the IFR logs in windbg, i got following response

kd > !wdfkd.wdflogdump ScDriver
ReadListEntry failed
Warning: It looks like you’re using the WDF debugger extension on a WDM
driver. Framework logs will not be available

ReadListEntry failed
warning: could not retrieve framework image for client driver ScDriver
Trace searchpath is:

Trace format prefix is: %7!u!: %!FUNC! -
ReadListEntry failed
warning: could not retrieve framework image for client driver ScDriver
ReadListEntry failed
hint: Are symbols available for this driver?
hint: Did you provide the correct .sys/.dll extension in the drivername parameter?

Could not find ScDriverin client list
ReadListEntry failed
hint: Are symbols available for this driver?
hint: Did you provide the correct .sys/.dll extension in the drivername parameter?

Could not find ScDriver in client list

**ScDriver **is my driver name.

I set the TMF file path to the file generated with pdb of my driver.

I could not see the log. When i tried to simulate the crash in my system, i could see the IFR logs properly with the crash dump generated on my system.

  1. Are IFR logs not persistent when the crash generated from different system from the one driver gets built ?
  2. SysCopyMemory is calling memcpy interally as far as i know. Are there any situations where SysCopyMemory can crash? Is there new/alternate API to do memory copy which does not crash if copy fails?
  3. does adding try and catch help here ?

With creash dump size, one different i see is on my system when crash is produced, the dump size is almost 2 GB. But the crash dump given by the customer is just 1.8 MB

I had set the dump type as “Automatic memory dump”.

Any help to troubleshoot my problem would be appreciated

Thanks

2

Your customer system is producing mini dumps, which are generally useless. However, you might get some information from !wdfkd.wdfcrashdump.

SysCopyMemory is just a macro that resolves to RtlCopyMemory, which as you understood correctly is just memcpy. There are many things that can go wrong with memory copies, which is why they are the target of a lot of malware.

3

Also remember that the CopyMemory family does not handle overlapping buffers. It’s almost always better to use the MoveMemory family, which DOES check for that.