Any experiences with the new 1607 WDK?

I see a new WDK to match the new Win 10 1607 release is on MSDN. Please chime in if you have had positive or negative experiences with it. I’m a little disappointed to see the EWDK, which the doc page says was last updated 8/11/16, still says no support for SDV and Code Analysis.

Jan

Looks like the EWDK download link still points
to EnterpriseWDK_Dev14_Release_th2_release_10586.zip. I couldn’t find the
1607 EWDK yet.

Regards,
Ajay Barboza

On Thu, Aug 11, 2016 at 8:38 PM, Jan Bottorff
wrote:

> I see a new WDK to match the new Win 10 1607 release is on MSDN. Please
> chime in if you have had positive or negative experiences with it. I’m a
> little disappointed to see the EWDK, which the doc page says was last
> updated 8/11/16, still says no support for SDV and Code Analysis.
>
> Jan
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> 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://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:>

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

(Make that the new WDK (RS1) and the *old* WDK ((TH2) do not work SxS.

Peter
OSR
@OSRDrivers

Sorry Peter, but the WDK requires the SDK, at least the limited SDK which is included to Visual Studio distro.

Since the Visual-Studio-included SDK is for TH2 for now (they also provide Win10 RTM and Win8 SDKs), is it compatible with RS1 WDK?

Or should we wait for next VS Update (2015 Update 4?) to use RS1 WDK?


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntdev…
> (Make that the new WDK (RS1) and the old WDK ((TH2) do not work SxS.
>
> Peter
> OSR
> @OSRDrivers
>
>

The SDK now ships with VS.

If you’re willing to upgrade to the RS1 WDK, then you should be good to go. Upgrade to the latest version of VS, install the 14393 SDK as part of the update, and install the RS1 (14393) WDK.

Except for the fact that (a) you will no longer be able to use the TH2 WDK (bug acknowledged by MSFT), and (b) there’s a bug in CA regarding the NX pool optin that we documented, you should be fine.

I’m running the RS1 WDK.

Peter
OSR
@OSRDrivers

Symbols for Wdf01000.sys cannot be found for me so I reverted to the 12586 for both the SDK and WDK. It looks like this is also the case for another OP on NTDEV list (https://www.osronline.com/showthread.cfm?link=278394).

Unfortunately, I could not find the link for the previous WDK setup program (wdksetup.exe) from Microsoft and I used a link from a third party web site. This is not recommended, I know.

There is a page for the so called SDK “archives” on Microsoft’s web site but I couldn’t find one for the WDK.

Anyway, I can debug wdf01000.sys with symbols and even KMDF sources from github now. I will work with this WDK later.

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

The lack of SxS compatibility has been fixed, by the way.

The plan is to publish a fix.

Just FYI to all.

Peter
OSR
@OSRDrivers