The UAC prompt takes a long time to come up on my laptop on both Windows 7 and on Vista. On my Desktop on Windows 7, it comes up pretty fast.

The issue, according to Chris Jackson at Microsoft, is that when the UAC dims the screen, it relies on the video card, and if the video card is slow to handle the dimming, then obviously you can't just get a new video card. The simple solution (in Windows 7) is to move the UAC setting down one level, such that it doesn't dim the screen. Unfortunately, I don't believe you have this kind of control in Vista.

Of course, not having the UAC dim the screen opens you up to spoofing attacks. But like anything else, hopefully your Anti-virus or Anti-spyware will catch the attack before it happens. Without the dimming, the prompt comes up instantly for me. Anti-virus/spyware isn't perfect, but there is definitely a trade-off with waiting for the prompt to come up. With dimming, it was taking a good 4 or 5 seconds for the prompt to appear, and another 4 or 5 for it to restore the screen. That's just far too long. It's a shame that the UAC prompt by default, relies so heavily on the video card (even in Vista). Fortunately, I've never come across spoofing of the UAC yet. Knock on wood. I don't want to disable the UAC prompt completely, because its saved my butt a few times, mostly from malicious ads that are on well-known, "safe" sites.

I have reported the issue to Microsoft as Windows 7 Feedback.

Issue 1 - explorer.exe using max cpu

A few days ago, I realized that after my laptop had booted up and had been running for a while, I noticed that it was a little sluggish. I opened Task Manager and saw that explorer.exe was using ~50% cpu (one of my dual cores) constantly. I then started to noticed that this happens every time I boot up. Not cool. It's not very easy to diagnose issues with explorer.exe since it's used so heavily from the Windows OS.

More specifically, right after I boot into Vista, I would open Task Manager and see that explorer.exe is running somewhere from 0 to 4% cpu, then about 15 seconds later, was when it would jump up to ~50%. After a few more reboots I was able to see that DpAgent.exe would jump from 0% to a constant 7% cpu usage at the same time that explorer.exe would jump up to 50. That's a pretty good indication DpAgent.exe is conflicting somehow, so I killed DpAgent.exe and sure enough, explorer.exe jumps back down to 0%. However, DpAgent.exe is my Fingerprint reader driver. I don't *need* it, but I sure would like to use it if the Fingerprint reader came with my laptop, ya know? Thing is, this conflict just started not too long ago (I would've noticed it months ago).

So now I'm trying to think about all the stuff I've installed recently. The most obvious was Java, since Java is notorious for running slower on Windows (at least not too long ago). I noticed I had a JDK installed along with two separate updates. I uninstalled all three, and sure enough, when I reboot, DpAgent.exe no longer causes explorer.exe to jump it's cpu usage.

Well, this sucks. Cause I've recently started using NetBeans IDE and I'd like the option of continuing to use it. (I also have it under Ubuntu dual booted on my laptop, so that's always an option to use it there as well). Anyway, I remember that when I installed NetBeans IDE, it comes with a Java SDK (that's how I originally installed the Java SDK.. through the NetBeans install.) But, how does NetBeans work when you install a new Java SDK? It turns out that there's a netbeans config file where you specify the path to Java, and I wasn't modifying this after Java was being updated.

So I decided to download the latest SDK from http://java.sun.com, and I found out that according to Sun, you *must* use the 64bit install if you are using a 64bit OS. I'm guessing NetBeans doesn't come with that (I don't see any 64bit download option for Windows on their site), so this could be the whole issue. Anyway, after installing 64bit JDK, I changed the NetBeans config file and all is good: The Fingerprint reader driver no longer causes explorer.exe to use 50% cpu, and I can still use NetBeans IDE with Java.

Issue 2 - tablet pc driver error

This has been happening for about the past three weeks or so. Upon bootup into Vista, I'd get a message saying "Tablet Service for consumer driver has stopped working", and my Tablet Pen would no longer work. This only happens some of the time. It's very random. I've tried disabling several different things, such as Nod32 Antivirus, Windows Defender, and other startup services, but I would still get the random crashes.

I was about to install a slightly newer version of the driver located at Wacom, but when I uninstalled the current Tablet Pen driver under Add/Remove Programs and rebooted, I noticed that the Pen still worked just fine. So I'm guessing there was a duplicate driver installed somehow at some point. Not sure exactly, but I'm not going to bother to install the new driver if all is working well as is. I've rebooted several times, and I no longer see the tablet service crash message. I've also read that installing the newer driver has caused some issues for some Tablet PC users, so I'd rather not mess with it anyway.

Anyway, the laptop is in optimal condition once again, so I'm happy. Maybe now I can get some coding done before my wife and I leave for Vegas and the Grand Canyon.

So you want to setup ASP.NET 2.0, Visual Studio 2005, and IIS7 on Vista Home Premium.

I don't want to repeat what someone has done a fantastic job of already, so here is a great article that covers quite a broad range of different scenarios:
http://learn.iis.net/page.aspx/431/using-visual-studio-2005-with-iis-70/

The article mentions one of the issues I had when trying to debug my web site application using Visual Studio 2005 against IIS7 (as opposed to the default ASP.NET web server) on Vista Home Premium. The error message displayed is:

Unable to start debugging on the web server. Debugging failed because integrated Windows authentication is not enabled. Please see Help for assistance.

The article mentions the following hotfix:
http://support.microsoft.com/kb/937523

One issue the article doesn't cover is when you try to view your site in a browser against IIS7 and get an error message similar to this:

CS0016: Could not write to output file 'c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files\application1\c11b43f6\cf3ec03\rizcntet.dll'. The directory name is invalid.

The following KB article has the fix:
http://support.microsoft.com/kb/825791
Even though the article says it applies to .NET 1.0 and 1.1, it works fine with 2.0. On the step where it says to...

Grant full permissions on the Temp folder to the aspnet user account in .NET Framework 1.0 or to the NETWORK SERVICE user account in .NET Framework 1.1.

...use the NETWORK SERVICE user.

Hope this helps someone out there. It took me a little while to find the fix for that last issue.