Saturday, September 17, 2005

Winlogon and Vista - stuck in the mud again

If you've been following my trials and tribulations with the changes to Winlogon in Windows Vista you know that winlogon notification packages are no longer supported. If you haven't been following this - then get with it and read the back issues.

In my last post on this topic, I mentioned that I now had basic rights elevation (as LocalSystem) working and was going to move on to replace the winlogon notification functions. Well I hit a nice big fat stumbling block on that! It turns out that in order to register for winlogon to provide your service with notifications of changes like logons, logoffs and the like you need to register to accept SERVICE_CONTROL_SESSIONCHANGE. To do this, you call RegisterServiceCtrlHandlerEx with one of the flags having the SERVICE_ACCEPT_SESSIONCHANGE bit set. I've been doing this in Visual Basic.Net so that it can be maintained easily in the company. I've done very little work with C (only a couple of smaller project like my original winlogon notification package and a windows password filter), so I don't really want to dig in and create a whole service using C.

It turns out that the thoughtful folks at Microsoft designed the .Net Framework to call RegisterServiceCtrlHandler instead of RegisterServiceCtrlHandlerEx. I'm going to presume this is so that it works on NT 4.0, since the Ex version is available on Windows 2000 and greater. This, like the bit about not supporting reg_expand_sz in the framework, is a killer. It means I can't find a way to get the VB.Net "Windows Service" base class "servicebase" to call the "ex" version of the API and hence I can't receive winlogon notifications. I'm waiting on a definitive answer back from Microsoft (it seems some of the folks "in the know" were off gallivanting at the PDC this past week). However it is looking more and more like I am going to have to hack this together myself in C instead of being able to rely on the .Net Framework for the plumbing stuff and just do the business logic and a few API's like you should be able to do.

This seems to be a recurring theme. The .Net Framework has all these cool classes that all almost let you do something. They tend to just fall short of the mark at actually letting you do something useful. You almost get there, then find limits. For instance, in VB.Net 2003, you can do cool owner draw menus and put an icon on them. Great! Now, try doing that with a TrayIcon. Oops! It won't work. Again, you almost get there. Anyone else have these same frustrations? Anyone else find they call Windows APIs in VB.Net darn near as frequently as they did in VB6? I know I sure do, but then again I am usually doing something like calling the security APIs which haven't really gotten much treatment at all in .Net.

Even more important: Anyone out there know how to get VB.Net to use RegisterServiceCtrlHandlerEx in a Windows Service and get access to the additional notifications? Post a comment with a sample if you do...

No comments: