We have a web application suite that has been working fine.

There are 4 VB6 WebClass applications that hand off flow from one to another.

The 1st gathers login info and presents a switchboard, the other 3 are the selections from that switchboard.

For those who are not familiar with the WebClass paradigm, there is a "front door" ASP. This instantiates a WebClassManager. Once instantiated, a method of that object is used to host the DLL that the VB6 WebClass project creates. That DLL has all the code that is developed—none of the code is in the ASP. The DLL is provided with references to the IIS Application, Server, Request, Response & Session objects.

I have created a support class that has a .Path & .File property, and a .Log method that writes text to the log file pointed to by the 2 properties.

All 4 of my web apps use this library (a ‘library of one,’ so to speak) by creating their own instance of it.

I have an EXE that is invoked with a Shell command from within one of the WebClass DLLs, and preforms its actions in accordance with command-line arguments provided to it. This EXE also uses the logging library.

Now, my understanding is that anything spawned by a program uses the same user account & credentials of the calling process to invoke the new one.


All of this has worked fine until the server computer was upgraded to Windows Server 2003, and the latest version of IIS.

But now, everything works fine except the EXE. All of the WebClass DLLs are able to perform their logging through the library. But in the EXE, when I try to set the .Path property of the logging library I get a "Registry Key could not be read" error.

I am mystified by how it could be that the IWAM user account could have the necessary authority/access to operate this library when running one of the WebClass processes, but a process spawned from that point does not.