Archive for the ‘Vista’ Category

Vista and Windows Error Reporting

Wednesday, October 25th, 2006

Wow, have we been busy. This week has been absolutely full of interesting ups and downs, from a software compatibility perspective. We’ve gotten through a lot of issues so far, and have make some nice discoveries along the way.

We had the good fortune of getting to talk with the Windows Error Reporting PM, who helped us solve a problem we ran into with how our software generates crash dumps in our ActiveX-based product. It turns out that the WER API is greatly expanded and can now do all of the things we need, so we can abandon our in-house solution on Vista+ and just use Microsoft’s. WER can be configured to send particular memory ranges, attach log files, and more.

Furthermore, the rumor is that they may even automate !analyze runs on reported crashes, using uploaded stripped symbols. I made the suggestion that they should allow ISVs to provide !analyze plugins (which Ken promises to document someday if Microsoft doesn’t get to it first). That would help with bucketing and initial auto-analysis even more. We’ll see what happens, but this is a great improvement over the pre-Vista APIs.

Worth checking out, if you haven’t yet.

Vista kd cheat sheet

Wednesday, October 25th, 2006

I am annoyingly scatterbrained and have had to look this up repeatedly this week. Here’s hoping I can save someone else the trouble:

c:\\> bcdedit /debug on
c:\\> bcdedit /dbgsettings serial debugport:1 baudrate:115200

Then reboot and enjoy.

NDIS6 stack usage

Tuesday, October 24th, 2006

While working with one of our drivers, Ken and I ran across an interesting stack fault that I’ve never seen or heard of on a pre-Vista OS. It turns out that the Vista network stack uses much more stack than previous OSes. Ken has all of the details.

My advice: if you have any sort of NDIS driver that goes above a basic miniport, you should be testing with Vista now. Install an IM driver or two, while you’re at it. NDIS-WDM drivers could have issues here as well.

Happy testing!

Microsoft Vista compatibility lab, day 1

Tuesday, October 24th, 2006

The first day of the Vista compatibility lab was… long. We got to the campus at about 9:00, and didn’t leave until 11:00 PM. This is the second time I’ve done something like this at Microsoft (the first was at Driver DevCon 2003, getting our network drivers running on NDIS6). It’s always a productive time – plenty of food, water, experts, books, and computers around so that there really are no impediments to getting real work done.

Vista is going to be an interesting challenge. The UAC stuff changed a lot in the last six months, and our software doesn’t quite interact perfectly with it yet. On the upside, the things that I thought were working – the drivers, for example – are indeed working. Other things are mostly clean-up work for code that was probably in need of clean-up anyway. There haven’t been many (any?) Vista-only changes that would break on downlevel OSes, which reinforces my claim that, if you are careful and code to the API in the documented way, you’re way less likely to break compatibility in the future.

Some of the experiences haven’t been quite so great, though; Ken found a seemingly very severe problem with IpHlpApi route addition, for example, and we’re seeing slightly different behavior from some other APIs in IpHlpApi as well – I fought with IpReleaseAddress for a while when it started returning a new (undocumented, of course) return code

And, of course, there are the major breaking changes – for example, GINA DLLs are gone, which may not mean much to 99% of software vendors out there, but if you happen to need a GINA replacement, you have to re-write that code completely and produce a credential provider instead.

In the annoyances category, there are things like icons looking bad (the dark grey task bar is hell on colorful icons) and high-res support in various places. And, ideally, we want to fully embrace the UAC system rather than fighting with it, which raises some interesting product design questions.

We made way more progress than I thought we’d make on day 1, and we still have most of the week ahead of us, so I’m optimistic that we can actually finish what we came here for. So far, so good, at any rate.

OK, last beef for the weekend, promise…

Sunday, October 22nd, 2006

We’ve had a lot to complain about this weekend, which isn’t normally my style, but since I’m in that kind of mood, I may as well add one more item to the list.

C:\\Users\\dispensa>telnet
'telnet' is not recognized as an internal or external command,
operable program or batch file.

No telnet?! This Vista thing is gonna take some getting used to…

UPDATE: An anonymous commenter points out that telnet.exe is simply not installed by default any more, but you can add it by going through the control panel. I guess this is better than nothing, but it was certainly annoying and the solution was non-obvious.

TDI is on the path to deprecation

Friday, October 20th, 2006

Mike Flasko posted to the Windows Core Networking blog with an entry discussing Winsock Kernel. He points out that it is the successor to TDI, and goes on to say that TDI in Vista is an emulation layer built on top of WSK:

On Windows Vista & Windows Server Longhorn, TDI is still supported for compatibility reasons; however, it has been implemented using a translation layer and thus its performance is sub-optimal resulting in performance degradation for TDI clients. For this reason, as well as others (TDI on path to deprecation, etc — see resource links below), drivers should opt to use WSK whenever possible.

He’s conducting a survey on the blog about WSK adoption. If you have a TDI driver, it would probably benefit you to get involved.

This has that standard everything before Vista is legacy feel that a lot of us have complained about before; I for one will have to continue supporting TDI for years, and I suspect I’m not alone. We are still shipping code supporting Win98 (although thankfully I’m out of the business of actually writing new Win9x code, but only recently).

Interesting stuff; worth a read.

Code analysis with Visual C++ Express Edition

Sunday, October 8th, 2006

I’ve blogged before about how much I like Visual C++ Express Edition, but it does lack one feature that I consider to be extremely important: code analysis using /analyze (i.e. PREfast). I pointed this out a while ago, and Michael Howard responded a couple of days later that the Vista PSDK compilers do support /analyze.

I finally got around to testing this theory out recently, and it works like a charm. With a little bit of one-time work, you can set this up for all of your projects. Here’s how:

  1. Get the latest Vista Platform SDK. This is available to beta testers via Connect and also via various other locations. Apparently this has been a part of the Vista SDK for a while, so even an older version should work, although I just tested with RC2 this weekend.
  2. Create a new configuration for your project in the IDE. I named mine Analyze. I copied all of my settings from the Debug configuration.
  3. Open up the property manager for the Analyze configuration and find the C++ command line section. Add /analyze to the command line. If you want to not count PREfast warnings as errors, you can also add /analyze:WX- in addition to /analyze. WX needs to be capitalized.
  4. Set the executable path using Tools->Options. Simply registering the SDK with Visual Studio is not enough – you have to actually manually add the compiler-specific BIN, LIB, and INCLUDE directories under the VC subdirectory of the PSDK.
  5. Finally, I had to change my system’s PATH environment variable to get Visual Studio to actually invoke the PDSK’s build tools in preference to its own.

I was able to get it working using both the IDE and vcbuild.exe by following this procedure. Compiling with /analyze takes a lot more time, and I’ve found that the PSDK headers aren’t actually quite PREfast-clean yet in a few places. There are also some bogus warnings about various APIs that return valid data lengths (i.e. recv()), but I had no trouble suppressing them with one-line warning suppression statements.

Using PREfast takes some getting used to, but in the end, I find it to be worthwhile. Oh, and incidentally, you can also get other features left out of Express Edition this way, like x64 compilers. Happy coding!

Channel9 Interview with Peter Wieland

Monday, September 18th, 2006

There’s a video of Peter Wieland up on Chanel 9. Peter is the development lead for UMDF and a regular contributor to the newsgroups and mailing lists.

There are also videos of Doron Holan discussing KMDF and Donn Terry discussing PreFAST, while you’re at it. I got the chance to meet Donn at the last MVP summit, and was really impressed. He’s exactly the guy you’d want working on PreFAST.

Good to see Channel 9 doing well post-Scoble.

NDIS needs updated types

Sunday, July 16th, 2006

Here’s hoping they change this for Vista (although it’s getting late…):

EXPORT
NDIS_STATUS
NdisAllocateMemoryWithTag(
    OUT PVOID *                 VirtualAddress,
    IN  UINT                    Length,
    IN  ULONG                   Tag
    );

That second parameter is a pain. Lots of APIs return SIZE_T for sizes or lengths of things, and SIZE_T is 64 bits wide on x64. But this API takes a UINT, so you need to use a cast a lot of the time. And you know how I feel about C casts.

In fact, there are only a few places in all of ndis.h that SIZE_T is used, and they’re all in new NetBuffer-related APIs. Compare that to the main headers:

C:\\WinDDK\\5384\\inc\\ddk>grep SIZE_T wdm.h|wc -l
48

C:\\WinDDK\\5384\\inc\\ddk>grep SIZE_T ntddk.h|wc -l
60

C:\\WinDDK\\5384\\inc\\ddk\\>grep SIZE_T ntifs.h|wc -l
33

C:\\WinDDK\\5384\\inc\\ddk>grep SIZE_T ndis.h|wc -l
5

I haven’t gone through the APIs to see where SIZE_T would be useful, but I suspect having zero non-NetBuffer SIZE_T APIs isn’t a good sign.

[UPDATED: fixed a confusing description, and again because Wordpres ate my homework...]

Microsoft’s Driver Quality rating system

Wednesday, June 14th, 2006

I just ran across this on Ars: Inside Microsoft’s new Driver Quality Rating system Microsoft will start assigning ratings – green, yellow, red – to drivers, and only green drivers will be allowed to run on logo-certified PCs. (You lose your logo if you ship a non-green driver.)

Interesting.