A "BlueScreen" control for ASP.NET???

I noticed the following post by "LennyBacon":
"Please Wait - Building a WaitScreen control for ASP.NET "

I had to read the title three times before I realized it wasn't a "BlueScreen control for ASP.NET".

Hey - that's maybe not such a bad idea - a BSOD .NET System.Web.UI.UserControl class! Something in the vein of Sysinternals' "BlueScreen Screen Saver" perhaps...

A project for a rainy day, I suppose...

USB Support in VMWare

This is probably covered in all kinds of documentation - release notes, read-me's, etc. While VMWare does support USB devices, it appears that only USB 1.1 is supported in the guest despite the fact that the host may support USB 2.0. VMWare KB article "Performance of Isochronous USB Devices in Workstation 5 Windows Virtual Machines" alludes to this...

I don't use USB devices with VMWare that much, but it's good that VMWare supports USB even if it's only 1.1.

"Insufficient System Resources Exist to Complete the API"

[Microsoft has made the fix for this problem generally available. More info here...]

My primary system is a laptop. My schedule typically doesn't offer the ability to have long "computing" sessions. Rather, I get 10 minutes here, 15 minutes there, etc. As such, I find hibernation to be indispensable. Open the lid, hit the button, and in under a minute, I'm back to where I last left off. After upgrading from 512 MB RAM to 1280 MB, I started having problems hibernating - I would close the lid on the laptop and if I walked by it several minutes later the power light would be slowly fading on and off, indicating that the computer was in "standby" rather than hibernating. Resuming the system would yield a black exclamation point inside of a yellow triangle in the Systray, with a bubble stating "Insufficient resources exist to complete the API."

Of course, this was less than useful. What API? What type of system resources? One could surmise the API to be PowrProf's SetSuspendState, but what about the resources? Process Explorer didn't show any process to be using anything more than one would expect it to (no NP pool hogs, no apparent handle leaks, etc). After this happened, "hibernate" would not be available as a "shut down" option. Only after rebooting would the option to hibernate become available again. And hibernate would work for a few days after a reboot. But then the little yellow triangle would pop up, and I'd have to reboot to get the hibernation function working again.

I finally got frustrated enough by this to start looking around on the Internet for people with similar problems. I ran into two discussions (here and here) about the problem, and the scenarios described often had several similarities to my scenario. Among them:

• dealing with a "large" quantity of RAM (>512 MB)
• using "large"/hoggish programs (Outlook, VMWare, Visual Studio .NET, etc)

After weeding deep enough through the discussions, I found a link to a Microsoft Knowledge Base article - "The computer occasionally does not hibernate and you receive an "Insufficient System Resources Exist to Complete the API" error message in Windows XP with Service Pack 2, in Windows XP Tablet PC Edition 2005, or in Windows XP Media Center Edition 2005".

The article exactly described my problem, and indicates the presence of a hotfix. The downside:

A supported hotfix is now available from Microsoft, but it is only intended to correct the problem that is described in this article. Only apply it to systems that are experiencing this specific problem. This hotfix may receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next Windows XP service pack that contains this hotfix.

To resolve this problem immediately, contact Microsoft Product Support Services to obtain the hotfix.

Of course, I'm severely affected by this problem. The batteries drain faster when the computer doesn't hibernate. Many people have stuffed their computer into bags / cases, thinking that they were hibernating. Imagine their surprise to find the system ready to cook eggs when they take the computer out of the bag, because the system was on (in "standby"), enclosed in a padded, tight case.

So, it looks like I'll have to try to get the patch from MS PSS. We'll see what happens...

Installing .NET Assemblies into the GAC

Junfeng Zhang has a good description of GAC Assembly Trace References. I find it interesting that an assembly that has been placed in the GAC by Windows Installer cannot be removed unless the application that placed the assembly in the GAC is uninstalled. If one tries to remove an assembly from the GAC that was installed by Windows Installer with GACUTIL (gacutil -u assemblyname), GACUTIL reports:

Unable to uninstall: assembly is required by one or more applications
Pending references:
SCHEME: <WINDOWS_INSTALLER> ID: <MSI> DESCRIPTION : <Windows Installer>

Number of items uninstalled = 0
Number of failures = 0

If one uses the Explorer Shell Extension for %windir%\Assembly, it
reports:

Assembly 'assemblyname' could not be uninstalled because it is required by other applications.

Troubleshooting SetupAPI.log

I've been tasked with creating an installation program that handles installing some drivers in anticipation that a certain piece of hardware will be connected to the computer. The objective is to automate as much of the driver installation and subsequent driver selection as possible, with the ideal goal being that the user doesn't have to do anything other than run the program and then connect the device.

Should be pretty simple. But given that I'm not versed in the Windows Installer technology, and InstallShield is as foreign as Baklava to me... Let's just say that I'm learning a lot. The initial cut of drivers (from a 3rd party, also responsible for the device) wasn't signed so there wasn't much I could do on XP / Server 2003 to make the process totally automated. But I got things as streamlined as possible. Then, out of the blue, and kind of in a fit of irony, we "magically" got signed drivers. The changes to the installation procedures were moderate (new files, new file names, fewer drivers, etc). But the recommended installation steps (provided by the 3rd party) were more tedious. After much trial and error, I've got things to the point again that there is nothing that the user needs to do other than run the program and plug the device in. The only problem is that the results are inconsistent - sometimes the driver appears to be associated with the device successfully, sometimes Windows says that I HAVE to reboot to get the driver / device working... and sometimes Windows says that there _may_ be a problem with the device. So it could be goofy drivers, or it could be a faulty device, or it could be...

All this led me down a path where I needed to know far more about the driver installation process than I suspected I would have to. But I found a great document at Microsoft's web site - "Troubleshooting Device Installation with the SetupAPI Log File". It's chock full of vitamins and information. I didn't have time to digest the full document, but I immediately noted the section "Appendix A: Setting the SetupAPI Logging Level". I skimmed and found that I could set [HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\LogLevel] to 0x2000FFFF. This will specify "that everything should be logged and that the log file should not be flushed to disk after each message is written" (to %windir%\setupapi.log). So I set the registry value and ran the installation program, and plugged the device in. Windows detected the device, found the driver, did it's magic... and reported that Windows needed to be rebooted (desipte the fact that I could begin using the device immediately). I opened setupapi.log and indeed all kinds of stuff was logged, including an entry toward the end that indicated the system would need to be rebooted because of an "unknown reason". The following excerpt is from the setupapi.log:

@ 15:40:40.775 #V282 Add Service: Modified existing service "SERVICENAME".
@ 15:40:40.785 #T214 Install Device: Writing driver descriptive registry settings.
@ 15:40:40.785 #T216 Install Device: Restarting device.
@ 15:40:40.955 #T217 Install Device: Restarting device completed.
@ 15:40:40.985 #W165 Device "USB\VID_XXXX&PID_XXXX\XXXXXXXXXXXXX" required reboot: Device not started (unknown reason).
@ 15:40:40.985 #T222 Install Device: Calling 'RUNONCE'/'GRPCONV' items.
@ 15:40:40.995 #I121 Device install of "USB\VID_XXXX&PID_XXXX\XXXXXXXXXXXXX" finished successfully.
@ 15:40:40.995 #T201 Install Device: End.
@ 15:40:40.995 #V156 Completed default installer.
@ 15:40:40.995 #V166 Device install function: DIF_NEWDEVICEWIZARD_FINISHINSTALL.
@ 15:40:41.005 #V155 Executing default installer.
@ 15:40:41.005 #V156 Completed default installer.

So either the driver's goofy or the device has issues. We don't really have control over either of them (3rd party), so there's not much that can be done in this particular case. But at least it seems I'm able to accomplish the ideal scenario if the device and the drivers behave properly.

Another interesting tidbit from the "Troubleshooting Device Installation with the SetupAPI Log File" document, again relating the the "LogLevel" registry setting:

Caution
Do not use 0xFFFFFFFF. This level turns on all logging, which results in an unreadable log file and some very slow installations.

Optimization for running VMWare VMs from a USB or other slow storage device

I love VMWare. Great product, innovative company. Recently had a minor problem after upgrading from Workstation 5.0 to 5.5, and wound up searching VMWare's knowledge base. Though I wasn't looking for this type of information at the time, I ran across an article that details a change one can make to a VM's configuration (.vmx) file that might improve performance. I haven't tried this yet, but plan on it the next time I have to move my VMs off of my laptop HD to an external HD (or *GULP* a network drive - yeah, yeah - I know).

Basically, VMWare uses a file in the VM's directory as a memory swap file. USB devices read and write data more slowly than internal HDs. So, VMWare uses a swap file on the USB device, and performance suffers. The suggested fix is to add the following setting to the VM's .vmx file:

mainMem.useNamedFile=FALSE

This tells VMWare to use the host system's HD to store the swap data.

The VMWare KB article is "Virtual Machine on USB or Other Slow Storage Device Runs Slowly".

"A principle terrain must be truth to aquire the state of a physical printer"

I've always liked this kind of thing. Over at Channel 9 on MSDN, they've got a "Knowledge Base Machine Translation Examples" wiki. The articles are RE-machine-translated back to English, so they're perhaps a bit worse than they would be if they'd only been machine-translated once.
Still, statements like the following are good fun:

A principle terrain must be truth to aquire the state of a physical printer

You show error 17803, if you execute a SORT- on a computer which has physical RAM multiple GB from SQL Server possesses,, or a CREATE INDEX operation on a computer,, which has physical RAM multiple GB from SQL Server possesses.

You engineers slogan are researching a resolution for this problem, which was denoted from user like you.

If it's an internal error, why am I seeing it? 42

I don't know that this needs much commentary. Name distorted to protect the guilty.

.NET Framework 2.0 Configuration Tool, Part 2

See part 1 or part 3 of this topic...


OK... Last week Shawn Farkas (MS) blogged in the ".Net Security Blog" about "Which Package are the Security Tools In?" for the .NET Framework 2.0. In that post, he states they're in the SDK package, which was discussed previously. No direct reason is given, but in one comment an individual notes that GACUTIL is also not part of the redistributable package as was the case with the .NET Framework 1.1. To this, Shawn replies that "GAC administration is not an end-user scenario". One can consider that similar reasoning was applied to the moving of the .NET Framework 2.0 Configuration Tool from the redistributable package to the SDK. Still, the tools are at the least handy for troubleshooting and I can easily envision many cases where I will be wishing I had them available without having to install the SDK on another system.

Diagnosing DCOM Problems

Looks like Windows XP SP2 and Windows Server 2003 (possibly only with SP1?) have added capabilities for logging information about DCOM activation failures and call failures. The document "Changes to Functionality in Microsoft Windows XP Service Pack 2" at http://www.microsoft.com/downloads/details.aspx?FamilyID=7bd948d7-b791-40b6-8364-685b84158c78&displaylang=en contains information about (among many other things!) the registry settings required to control the additional logging:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole]
"ActivationFailureLoggingLevel"=dword:00000001
"CallFailureLoggingLevel"=dword:00000001

Setting the values to 0 turns the logging off. For the change(s) to take affect, the DCOM server needs to be restarted. This may require rebooting the system, depending on what the DCOM server is.

The settings cause the following types of messages to be logged to the System event log.

The machine wide limit settings do not grant Remote Access permission for COM Server applications to the user NT AUTHORITY\ANONYMOUS LOGON SID
(S-1-5-7). This security permission can be modified using the Component Services administrative tool.

The machine wide limit settings do not grant Remote Activation permission for COM Server applications to the user NameSamCompatible SID ({sid}). This security permission can be modified using the Component Services administrative tool.

This allows one to determine what permissions need to be added to what accounts.

A knowledge base article that also documents these registry settings is:

Programs that use DCOM do not work correctly after you install Microsoft Windows Server 2003 Service Pack 1

.NET Framework 2.0 Configuration Tool

See part 2 or part 3 of this topic...

ACK! What was Microsoft thinking? The .NET Framework 2.0 configuration tool (MSCORCFG.MSC Management Console) doesn't ship as part of the .NET Framework. Rather, it comes with the .NET Framework 2.0 SDK.

http://msdn2.microsoft.com/en-us/library/2bc0cxhc.aspx

In the .NET Framework versions 1.0 and 1.1, Mscorcfg.msc is installed with the .NET Framework redistributable package. Starting with the .NET Framework 2.0, Mscorcfg.msc is installed with the .NET Framework SDK.

This is a change from the .NET Framework 1.0 and 1.1, where the installation of the Framework put shortcuts in "Administrative Tools" for "Microsoft .NET Framework 1.1 Configuration" and "Microsoft .NET Framework 1.1 Wizards" for the .NET Framework 1.1, and similarly named tools for 1.0.
Sure, there are command-line tools that one can use to do much of the same things, but why remove the UI? The only thing I can think of is that if something's not there, someone can't play with it. But even if the Framework install lays down mscorcfg.msc, it wouldn't have to install a shortcut to it - that right there would probably keep 99% of the people away from the program. If someone needed it and knew it was there, they could browse to it and run it.

Seems odd. I hope to be able to do a bit more digging to find out why this tool isn't included as part of the base Framework install.

Process Explorer 10!

A new version of Process Explorer from Sysinternals was released! Version 10.02 is a major upgrade and has a bunch of new features. Details and download (FREE!) are at:
http://www.sysinternals.com/Utilities/ProcessExplorer.html

Can't wait for Process Monitor!

"Protecting against Pointer Subterfuge"

Michael Howard has a good post about "Protecting against Pointer Subterfuge" and he introduces some functions that are new to Windows XP SP2 and Windows Server 2003 SP1:
EncodePointer and DecodePointer
EncodeSystemPointer and DecodeSystemPointer

"Root Kit" by "Patch Me Up"

Whoa.
This is over the top.
Words can't do it justice.
You just have to see it.
http://video.google.com/videoplay?docid=9151435244001559688
Insane.

#import - undocumented attribute "no_function_mapping"

I've been working with a rather complex library of 3rd party COM components. One type-library is imported and there are a total of about 3,000 methods. As a result of what I presume to be the 3rd party not adhering to one of "The Rules of COM 101" ("published interfaces are immutable"), I'm kind of in a situation where I need to modify the code generated by the #import (the .tli file, at least).

I #imported the type-library with about 10 attributes to generate the .tlh and .tli files. Then I commented out the #import directive and just #included the .tlh, which in turn #includes the tli. In my case, I needed to modify the .tli so that instead of using the hard-wired DISPIDs that the compiler brought in with the #import, IDispatch::GetIDsOfNames is called to determine the DISPID at runtime. Of course, doing this more than once per program execution isn't efficient, so I wound up creating a local static DISPID variable to hold onto the value, and then a local static bool initialized to false to be the flag that indicates if the DISPID needs to be determined or not. To be thread safe, I entered a critical section prior to testing the bool, and leave the critical section immediately after determining that I've got the DISPID (either in this run, or in a previous one).

One attribute that came in handy in the #import is an undocumented one, "no_function_mapping". This attribute is mentioned in the MS KB article "Description of the no_function_mapping compiler directive and the implementation_key compiler directive in Visual C++ .NET or in Visual C++ 2005". Basically, the "no_function_mapping" attribute is used to disable the "implementation_key" compiler directive, which is used when a type-library has more than 1000 methods. In my case, I didn't need the "implementation_key" (in fact, it kind of cluttered the code) but apparently in other cases it actually causes compiler errors (documented in the KB article).

I don't usually advocate changing compiler-generated code but in this case I made an exception as I plan on thoroughly documenting what I did as well as WHY I did it, and how the idea can be carried forward should additional or newer methods in the 3rd party library be required.

Kill 'em all!

Thanks, Visual Studio .NET 2003!

Good thing it's only the life of a process at stake...

I love the "Corrected Source" Code here...

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcepbguide5/html/wce50grfPREfastWarning253.asp

This is golden:

Example
    Defective Source
        MmSecureVirtualMemory(NULL, 0, 0);

    Corrected Source
        // use something else

Connect to the console session on a server with Remote Desktop Client

Remote Desktop is a great feature, but sometimes you want to get to the console session on a remote system (rather than another, new session). The Terminal Services Console connection program (mstsc.exe) accepts some command line parameters, one of which is "console". This parameter allows you to connect to the console session on a server. If you run "mstsc /?", the "Usage" dialog displays, detailing more options.

Free GSX Server?

Rumor has it that VMWare may soon start giving away their "lower-end" server virtualization product, GSX Server, for free. A pretty bold move, to be sure, but I think that it well serve them well. If people like GSX server they may be more inclined to upgrade to the higher-end product, ESX server, which doesn't require a host operating system.

A new kind of password

http://clam.rutgers.edu/~lsobrado/graphicalpassword/
GraphicalPassword requires the .NET Framework 1.1. It's experimental, but an interesting concept. Your password is made up of specific icons. Many icons are presented and the idea is to find yours and click somewhere inside the perimeter created by extending imaginary lines out from your icons.

A corresponding article:
http://rutgersscholar.rutgers.edu/volume04/sobrbirg/sobrbirg.htm