[Last updated 31 Aug 2016, 16:11 Eastern time]
Update: As of 31 August 2016, we have verified that RS1 symbols are now present and indexed on the MSFT Symbol Server. Yay! We’re back in business!
The hits to driver developers just keep on coming when it comes to RS1.
The latest? The symbols for WDF01000.SYS and WDFLDR.SYS aren’t on the public symbol server. We had heard rumors of this, but we didn’t actually see this ourselves until last night.
That’s OK though, because the symbols ARE in the downloadable symbol package that’s available from MSDN. So, crisis averted, right?
It seems that the symbols for NTKRMLMP are missing as well. Well, at least for the version of the OS image that was pushed to my debug target machine.
Not having the symbols for the OS image makes your target machine effectively not debuggable. Nothing’s more fun than typing !wdfldr and getting back 10 pages of boxes surrounded by stars explaining to you that “Either you specified an unqualified sum,bol, or your debugger doesn’t have full symbol information” as it tries to resolve the symbol
We’ve put in a call to our friends at MSFT on this one. They were thankfully quick to respond and are looking into the problem as I type this. We’ll update this post as soon as we have more information to provide.
Maybe you’re asking yourself: Why would the folks at OSR update their target system to RS1? Yeah, well, that’d be a good question. Ignoring the fact that if you’re going to support RS1, you better actually test on RS1… there’s this little issue of “automatic updates.”
My target system is on the network because I’m debugging it using the NET KD transport (a whole other issue… I want my 1394… but I digress). Because my target system is on the network, it got upgraded a couple of nights back to RS1. That wouldn’t have been so bad… except, well… you know. It put me out of business in terms of debugging.
Maybe I’ll just take the weekend off and tell the IHV that their driver will be late because I can’t do any reasonable debugging. Right. That’ll work.