Suggestions for debugging/diagnosing a failed driver callback?

NTDEV
1

I have a UMDF driver based upon the Microsoft video/IndirectDisplay sample. After making some changes to add support for multiple monitors, I’m getting a STATUS_INVALID_PARAMETER error back when calling IddCxMonitorArrival().

IddCxMonitorArrival is an OS callback function the driver calls to report a monitor arrival. Before the call returns, two of my event handlers are called by the OS(1). Usually when something like this happens, it’s due to an event handler returning a non-success status, but I’ve looked at both of my handlers under a microscope, and everything seems correct – they’re both returning STATUS_SUCCESS.

The documentation for this function just has the usual “returns STATUS_SUCCESS if successful; otherwise an appropriate NTSTATUS error code”.

I’m using WinDbg. Any suggestions on how to diagnose something like this?

(1) Each is called twice, actually; the first time to request a buffer size, and then again to get the info.

2

Step 1: Enable WDF Verifier, and Verbose logging. Repro the problem. Then dump the log (!wdfkd.WDFlogdump)… see what you see.

You might also ensure that Windows Driver Verifier is enabled in your driver and the Framework.

That’s a start, at least…

Peter

3

Since the failing function is an IddCx callback, I added a trace provider for IddCx:

logman create trace IddCx -o c:\dev\IddCx.etl -ets -ow -mode sequential -p {D92BCB52-FA78-406F-A9A5-2037509FADEA} 0x000004F4 0xFF

I was already using TraceView (and WinDbg) to view WPP messages in my own driver, and I can see the additional trace output from IddCx, but the messages aren’t getting resolved:

... display-driver  ... MyCode::CMonitor::OnIddCxMonitorQueryTargetModes(iddCxMonitor: 0xFFFFFDDF2FA0DB28, pInArgs: 0x000000F71547F298, pOutArgs: 0x000000F71547F2F0) {
... display-driver  ... } --> STATUS_SUCCESS  // MyCode::CMonitor::OnIddCxMonitorQueryTargetModes
... Unknown         ... Unknown( 10): GUID=007c3300-d434-37e7-88ed-f862ee134897 (No Format Information found).
... Unknown         ... Unknown( 10): GUID=007c3300-d434-37e7-88ed-f862ee134897 (No Format Information found).
... Unknown         ... Unknown( 13): GUID=48d282b8-c2d5-367a-a00c-0c88630ce62d (No Format Information found).
... display-driver  ... MyCode::CMonitor::OnIddCxMonitorQueryTargetModes(iddCxMonitor: 0xFFFFFDDF2FA0DB28, pInArgs: 0x000000F71547F298, pOutArgs: 0x000000F71547F2F0) {

I’ve pointed at the IddCx.pdb, etc. I’ve updated all my symbols from MSFT. I’ve tried everything I can think of.

4

I’ve tried everything I can think of.

Except, apparently, what I suggested earlier.

Peter

5

I see now that I was supposed to add my driver filename as an argument. Since I haven’t used !wdfkd.WDFlogdump before, I didn’t know what to expect – I originally guessed that I wasn’t logging successfully, thus my last question

6

… AND enable WDF Verifier. And WDF KD Verbose logging. And Windows Driver Verifier…

Peter

7

AND enable WDF Verifier
I enabled WDF Verifier (assuming that’s the same as WDF Test Features Control Panel). I enabled VerifierOn, DbgBreakOnError, VerifyOn, and VerboseOn for my driver. I also enabled VerboseOn for IddCx.dll.

…And WDF KD Verbose logging
On the WDF Verifier Settings tab, I set Tracing level: to Verbose Output (All Events of Any Sort)

I spent about a day fussing with this, because it was in a loop bringing up copy after copy of WinDbg on the test system when I was trying to debug remotely.

…And Windows Driver Verifier

I spent another day fussing with this. I didn’t realize this was a KM-driver-only utility, so instead of pointing it at my UMDF driver, I went with the defaults. I’m doing initial testing on a Virtual Box VM, and I kept getting bugchecks in vbox drivers. Using the command-line in the Windows recovery menu, I tried fine-tuning the verifiersettings to exclude the driver or not perform some test.

After lots of cycles with no luck, I realized that nothing I did on the command line (including resetting settings) was having any effect after rebooting (maybe something to do with VirtualBox). I had to do a VM restore to get out of the loop. Using the UI, I can successfully change verifier settings, but even excluding all of the non-Microsoft (e.g. VBox) drivers, I still get hung up on some Bug Check in an MS driver with VBox*.sys somewhere in the stack trace. Maybe the idea was to exclusively verify WUDFRd.sys?

Without Driver Verifier, I was still able to get additional, combined trace output from my driver. Unfortunately, everything from IddCx looked normal, and there weren’t any trace messages (besides my own) in the section of interest (between the driver callback, the event callbacks and the error return).

I am trying to follow your recommendations. I didn’t list out all the steps earlier, because I didn’t want to flood you with a wall 'o text. If I’m not on the intended path, it may be due to the fact that I’m swimming in uncertainty on a number of points…

8

If you don’t TELL us you’ve done something (like enabled WDF Verifier or Verbose logging), there’s no way for us to know that you’ve done it.

So… nothing in the WDF log output to indicate what is failing? That is disappointing.

You can try enabling WDF Verifier (and verbose logging) on IndirectKMD as well… and maybe dump his log.

Not being an IddCx expert, or even a user of IddCx I’m afraid the only advice I can give you is general WDF stuff.

Sorry I can’t be more helpful,

Peter