New in WdfVerifier- the tweaks and fixes
Now that the PDC is underway, and WinHEC is nigh, I'm going to provide a quick peek at changes coming to the WdfVerifier tool (these will be in the Windows 7 Beta WDK, which isn't far away, but obviously I still can't say more than that).
Doh!
First off, fixes for a few of the usual boneheaded bugs (please note these were my bugs, not bugs in the underlying KMDF or UMDF code):
- Handle Tracking settings for KMDF were being managed in an incorrectly named value.
- Paths to UMDF debugger with spaces in them weren't handled properly
- Any attempt to change UMDF host process restart limit set it to the maximum value (one of those last minute changes that slipped past an ad-hoc test procedure).
- The thread that handles UMDF auto-launch never idled. Didn't think it mattered, as it was normal priority, but it sucks laptop batteries down fast when it doesn't.
- There was a reference counting error in my object management code- if you had UMDF drivers installed and ran for a very long time, the resulting leak from the auto-launch thread would eventually do the usual low-memory nasty things to you.
There were a few typos and a lot of rather poorly expressed concepts (probably some grammatical errors as well) in the tooltips [although I'm often tempted to rewrite the lot of them every time I look at them].
Added touches
- I now show you the start type of each KMDF driver (when you select it).
- When running locally (and where I can, I also do this remotely for KMDF runtime) the true WDF version information for the runtime and each client driver are presented. I overwrite any version info the coinstaller wrote (which we know is untrustworthy) with the real stuff when I find it.
- Tool settings for the app itself are now managed by machine name (they have always been per-user, as well)- so you can have different preferences for local and remote, and even different settings for each remote machine you manage with it [not that this was in high demand- it was just easy to do and harmless enough].
- I tried to unclutter the UI a bit (but new features cluttered it back up fairly quickly). I may try to do something more drastic after Windows 7.
- There are some new features in KMDF 1.9 that only apply to KMDF 1.9 client drivers- so the UI now changes a bit when you have a 1.9 or pre 1.9 driver selected.
- I realized there was a smarter way to show how the handling of WdfVerifierBreakPoint and the WDFVERIFY macro work with respect to the overall Framework verifier settings (drop list instead of checkboxes that mysteriously changed settings on you in unexpected ways).
- I added a splash screen- it's a bit klutzy, but at least you don't sit wondering what's happening after you invoke it- it provides some progress messages
- Eliyas said he wanted an icon, so being cheap, I made one (the letters WDF in blue with a green check mark sketched in as a background), rather than try to find a real artist.
The method for determining the client version of a KMDF driver and for that matter of the runtime was fun and might interest some readers, so I'll blog about that shortly. But don't expect much code- I don't believe in samples, I believe in concepts, but I hashed out my thoughts on the subject of sample code in part some time ago.
So here's the next 1000 words (I'd show you a 1.9 inbox driver, but that would reveal things to be disclosed at WinHEC) - KMDF tab (on all snapshots I've added some highlighting or markup for new stuff):
Here's the UMDF tab- the list of drivers would also show, but I didn't have any handy and am short on time (I'll snap one for a later post, perhaps):
Preferences page has a new control related to the harvesting of KMDF version info (you only see this when running against the local machine)- it's there because it can take some cycles, so you only want to repeat it when you really think you need the info (first time through registers it results, so once might be enough):
Did I mention a (less than awesome, admittedly) splash screen so you don't get bored while it loads? When it is scanning for drivers, it lists each service- I could keep trying to get a snapshot right when a real driver is being looked at, but I'm not. So the one here has nothing to do with drivers...
Enough pictures for now- probably more than you needed. Next time I'll talk about the easy parts of getting version information, then when I find time, I'll talk about the fine hacks I made to get the real KMDF client driver versions, and you can decide if you even want to let this code near your machine...
Now Listening: Grateful Dead- Built To Last [album]- Blow Away
