by Across various presentations at WinHEC, several new tools have been introduced for use by Windows driver writers. There’s no real overarching theme to these tools, they touch different parts of the driver development process and don’t necessarily all target the same audience. However, they’re new and potentially useful, so I thought it worth summarizing them here for your convenience.
The INF Validator
It’s a bit of a shame that in 2015 we still install our PnP drivers using INFs, which haven’t undergone any significant change or improvement since Windows 2000. INFs end up mostly being boilerplate, but they’re very prone to error due to their odd rules and syntax. Microsoft has been keenly aware of this problem and attempted to address it over the years with various tools in the WDK.
Remember GenINF, the utility to magically generate INFs? No? Don’t worry, it didn’t really work anyway and last appeared in the Vista WDK.
ChkINF was a far more useful tool that checked your INF for syntax violations. This saved you from typos and places in your INF where you mistakenly had “,,12,,,,1” when you meant to have “,,%12%,,,,1” (duh!).
INFTest was a repackaging of ChkINF, so it had all the same goodness as ChkINF. However, both INFTest and ChkINF had a major downside: even if you passed these validators it didn’t necessarily guarantee that your driver would install properly.
Enter the INF Validator! Apparently this tool validates your INF by using the same code that the installation procedure uses to actually install your INF. Not an interpretation of the code. Not a set of guidelines that the code expects your INF to adhere to. But the same code, just used to validate instead of install. Pretty neat!
The Inflight Trace Recorder
This one is specific to WDF driver writers. All WDF driver writers should be familiar with the WDF Log, which is an in memory trace of the Framework’s activity that can be dumped from the debugger with !wdflogdump. Starting in Windows 10, driver writers will be able to add their own entries to the WDF Log. Now instead of just seeing Framework activity prior to a system crash you can see driver and Framework activity intermixed.
Additional Windows Performance Analyzer Integration
This one is again specific to WDF driver writers. Here at OSR we love Xperf and the Windows Performance Analyzer. They allow an amazing level of detailed information to be collected in a Windows system for the purpose of performance analysis. The trouble, however, is always in interpreting that data and turning it into actionable changes in your code to resolve performance issues (or squeeze out that next bit of performance).
The next versions of the Frameworks will contain additional trace points to allow for better analysis of performance issues in Framework drivers. Details are scarce on this at the moment, but we’ll keep you updated with additional information when we have it.
ACPIGenFx
This one has a pretty narrow focus, but we thought it was too cool to not mention. An ACPI BIOS contains a series of ACPI tables, which are described using the ACPI Source Lanuage (ASL). ASL is compiled into ACPI Machine Language (AML) using the ASL Compiler (asl.exe) and then interpreted by an OS provided ACPI Machine Language Interpreter (AMLI). The trouble with this is that the AMLI in Windows in not very forgiving. If your ASL is incorrect for whatever reason, you very quickly brick your machine.
The ASL compiler finds syntax errors during the compilation process, but just like any other compiler that doesn’t find logical errors in the code. Enter ACPIGenFx, which is a C# library specifically for generating OS independent ASL. Instead of just writing your ASL to text file, you make a series of C# calls to describe the tables you’re creating. At build time, ACPIGenFx checks that the resulting ASL “makes sense” and also validates any Windows specific requirements. Assuming that everything checks out, the result of the build is a validated ASL file.
WDK10 and VS2015?
We’ll also have a new WDK and Visual Studio version to check out. It’s always possible they’ll contain something new that wasn’t mentioned in the WinHEC presentations. We’ll continue to update as details emerge.
OSR Open Systems Resources, Inc.