Thanks for the blog posts about the new WDK. I did install the new WDK earlier this week and today discovered a few interesting “features”.
So I have two drivers that code analysis and SDV say pass, as they did before, but then I went to generate the DVL file to give to the WHQL tests, and it said I had MUSTFIX errors. On further investigation, both drivers had functions that used more than 1K of stack space, even though they had a modest number of 32 and 64 bit locals, no way did it add up to 1K. On further investigation, I realized the TraceLogger entries allocate a private structure, for EACH trace message, and yes I had a bunch of trace messages. On #ifdefine’ing some of the trace messages, the too big stack frame went away.
It’s not clear if the new WDK is just pickier about code analysis of frame sizes, or something about TraceLogger messages is taking more stack space.
I’m a little surprised that TraceLogger messages each use unique stack space, and am not sure why the compiler just doesn’t make their stack spaces all overlap. It seems like the stack space needed should be the largest trace logger metadata record, not the sum of all of them. I’ll have to look at the code after the preprocessor munches the trace logger macros. It did not seem to be a problem under the older Win 10 WDK.
I’ve developed a mixed opinion of tracelogger tracing. It does generate larger traces, although I still seem able to trace low level events like ISR/DPC interaction down to about 0.3 uSec resolution. Activity ids and related activity ids are also just incredibly useful to filter trace files. Like I generate a new activity id when I get an interrupt, and tag all the events directly related to that interrupt, and then can easily filter a trace of a million events to only those related to this one interrupt. This feature alone is way better than WPP. Newer tools on newer OSs can mostly decode the TraceLogger events, although I’m still wondering if there is a way to have semi-permeant tracing of errors enabled. This was pretty well defined for manifest based ETW events. If trace logger turns out to use lots of stack space on the new WDK, I’m going lower my opinion of it.
It did take an hour or two to get two drivers compiling correctly again on the new WDK, and initial smoke tests say they work. So far, I have not had anything forcing me to revert. The subtle gotchas are still being discovered.
Jan
On 8/12/16, 5:16 AM, “xxxxx@lists.osr.com on behalf of xxxxx@osr.com” wrote:
There are some issues we talked about in our blog and on the OSRHINTS mailing list:
https:</https:>
Think before you update! The new WDK and the new WDK do not work side by side as they should.
Peter
OSR
@OSRDrivers