Debugging storport using symbol storport!_RAID_UNIT_EXTENSION

I was debugging a storport miniport and following the directions at https://blogs.msdn.microsoft.com/ntdebugging/2012/06/21/what-did-storport-do-with-my-io/ was trying to look at the internal state of storport.

On the two different OS flavors I looked at (x64 Server 2012 R2 upd1, and x86 Win 8), what is supposed to be the storport device extension, symbol storport!_RAID_UNIT_EXTENSION did not seem to match up with what was really in memory at the device extension. The first few fields did seem to match (like a pointer to the driver object is correct), but later in the structure, windbg just displayed nonsense values. Windbg was using the Microsoft symbol server, and seemed to think the symbol files did match the executing binaries.

Has anybody recently debugged a storport driver and used storport!_RAID_UNIT_EXTENSION? I’m looking for a reality check of yes the public storport symbols are broken, and it’s not at my end, or else that other people have found these symbols do match up, and I should investigate why something is my windbg environment is causing the symbols to be interpreted incorrectly.

Thanks,
Jan

Apparently, my brain was suffering from temporary data corruption when it suddenly context switched from network drivers to storage drivers.

This issue was because I was applying the PDO device extension structure to the FDO device extension. It seemed like it matched up because some of the early fields do match up. The symbol storport!_RAID_UNIT_EXTENSION is for the per storage target PDO, as storport is a bus driver and creates a PDO for each target. The symbol storport!_RAID_ADAPTER_EXTENSION should be the structure for the FDO extension. I’ve written virtual bus drivers a bunch of times, so understand the FDO/PDO relationship well. The term UNIT did not connect as a synonym for PDO without a little more poking around.

The windbg extension for storport also decodes a bunch of the useful data in the device extensions.

Jan

From: on behalf of Jan Bottorff
Reply-To: Windows List
Date: Sunday, January 29, 2017 at 11:37 PM
To: Windows List
Subject: [ntdev] Debugging storport using symbol storport!_RAID_UNIT_EXTENSION

I was debugging a storport miniport and following the directions at https://blogs.msdn.microsoft.com/ntdebugging/2012/06/21/what-did-storport-do-with-my-io/ was trying to look at the internal state of storport.

On the two different OS flavors I looked at (x64 Server 2012 R2 upd1, and x86 Win 8), what is supposed to be the storport device extension, symbol storport!_RAID_UNIT_EXTENSION did not seem to match up with what was really in memory at the device extension. The first few fields did seem to match (like a pointer to the driver object is correct), but later in the structure, windbg just displayed nonsense values. Windbg was using the Microsoft symbol server, and seemed to think the symbol files did match the executing binaries.

Has anybody recently debugged a storport driver and used storport!_RAID_UNIT_EXTENSION? I’m looking for a reality check of yes the public storport symbols are broken, and it’s not at my end, or else that other people have found these symbols do match up, and I should investigate why something is my windbg environment is causing the symbols to be interpreted incorrectly.

Thanks,
Jan


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