How can I debug a VB6 IIS Application on Windows 7 64-bit

Question

I have a need to be able to debug a Visual Basic 6 IIS Application on Windows 7 64-bit. Not just for a single problem but for continuing development.

An attempt to debug results in an error "An unspecified error has occurred" from the WebClass runtime.

If I do not debug and simply access the compiled webclass the page loads just fine. Therefore, I don't believe there is anything wrong with the registration / configuration of the application but rather this is somehow related to Windows OS security blocking the VB6 IDE from hooking into IIS and allowing it to debug.

Here are all of the things that I have tried:

1. Disabled User Account Control (UAC) and rebooted.
2. Modified DCOM component security for machine debug manager (MDM) and assigned "Everyone" launch and activate permissions.
3. Manually added DCOM entry for "70F214BA-94E2-4bdf-8F30-32CB4A905E4D" which is the VB6 IDE and assigned "Everyone" launch and activate permissions.
4. Disabled Windows Firewall
5. Ran the application (VB6.exe) in compatibility mode of Windows XP SP3 with run as administrator option.
6. Created a new IIS application pool with an identity set to an administrator account. Set the application pipeline mode to classic and enabled 32-bit legacy application support.

This exhausted my extensive experience of things to try. If I create a VB6 Windows Application or ActiveX control I can easily launch and debug.

I've experienced a very similar problem on Windows Server 2003 although a fresh install of W2K3 resolved the problem.

In the Windows System event viewer log there are 2 duplicate entries for Event ID 10004 as follows:

DCOM got error "1326" and was unable to logon DOMAIN\User in order to run the server: {70F214BA-94E2-4BDF-8F30-32CB4A905E4D}

Where DOMAIN\User is my domain account and the GUID mentioned above is the DCOM entry I added for VB ASP Debugging.

The only extra information I have to offer is that Windows 7 64-bit is running in a VM although I am remoted to the console while attempting to debug. I've experienced problems debugging on VMs without a console connection.

If anyone can offer any further suggestions of things to try I would greatly appreciate it.

If anyone can figure this out and succesfully debug an IIS web application on a Windows 7 OS depicting the necessary settings I will offer the current bounty of 300 points!

Answer 1

I recently experienced the same problem on my Windows 7 64 bit machine. The solution that worked for me was to check the windows event log (system) for the specific DCOM error. This is the error that I had:

The machine-default permission settings do not grant Local Activation permission for the COM Server application with CLSID {17C2D338-9569-4022-8AF2-52A3A124F22D} and APPID {17C2D338-9569-4022-8AF2-52A3A124F22D} to the user NT AUTHORITY\IUSR SID (S-1-5-17) from address LocalHost (Using LRPC). This security permission can be modified using the Component Services administrative tool.

The key point for me was to give the IUSR built-in account Launch and Activation permission. After attemtpting to give this user permission to the individual DCOM components and failing, I decided to add the user to the default DCOM permissions for the machine. You can do this as follows:

Run dcomcnfg. Right click on the Console Root/Component Services/Computers/My Computer node. Select Properties. Select the 'COM Security' tab. Click the 'Edit Default' under the 'Access Permissions' group. Click 'Add'. Enter the User indicated in your event log (mine was IUSR). Click OK. Repeat for the 'Launch and Activation Permissions' group. Select OK on all the dialogs.

I did not have to reboot my machine for these setting to take effect. I used the same method to debug the VB6 dll that I used on XP i.e. run the dll under VB6 (unattended execution), set a break point, navigate to a page that accessed the dll, and wait for the breakpoint to be hit. Hope this helps.

Answer 2

Don't know if this helps you further.. I am researching the same issue my own use.

In even viewer I see: The machine-default permission settings do not grant Local Activation permission for the COM Server application with

CLSID 
{08855658-7A0B-4EF9-99B2-0AF875B3E62A}

and

APPID 
{08855658-7A0B-4EF9-99B2-0AF875B3E62A}

to the user NT AUTHORITY\IUSR SID (S-1-5-17) from address LocalHost (Using LRPC). This security permission can be modified using the Component Services administrative tool.

..so I attempt to grant Local Activation to "Everyone" - Just to see if I can make it go away. -I Can't.

Then I grant Local Activation as a default in Component services / my Computer (properties) COM Security, Launch and activation permissions

I still can't debug, but I no longer get errors in event viewer. In browser I get

Server object error 'ASP 0178 : 80070005'

Server.CreateObject Access Error

/app.asp, line 4

The call to Server.CreateObject failed while checking permissions. Access is denied to this object.

The CLSID above is my vb6 app, but registry points to vb6debug.dll (which looks right). progID match etc.

Granted permissions to everyone on the vb6debug.dll and other files.

Next step is procmon or something like that to see what happens.

Answer 3

I believe it is not possible to debug a VB6 IIS Application in IDE on any version of Windows newer than Windows XP (probably, situation is similar for server flavor of Windows). The root cause of the problem seems to be major differences between IIS 6 and IIS 7+. Of course, there is no official documentation on the topic, thus I shall go into more details below.

First, it makes sense to recap the problem. Many good folks seem to forget that IIS Application is an exact term referring to special type of VB6 project in this context. I was able to reproduce the error following these steps on Win7 Ultimate x64 SP1, Win7 Ultimate x86 SP1, and Vista Enterprise x86 SP2:

1. Install VB6 and SP6.
2. Create new IIS Application project:
3. Save the project.
4. Choose Run -> Start (F5) to debug the project.
5. Choose any option on Debugging tab and press OK:

Immediately after that there is error message in VB6 IDE:

Let us examine what happens when the same scenario is executed on Windows XP. When one starts debugging VB6 IIS Application:

• VB6 IDE starts IIS service if it is not running:

• VB6 IDE prompts to choose IIS virtual directory:

All this happen on Windows XP before WebClass is activated. Process doesn't get to this stage on Windows 7.

It is clear that VB6 IDE attempts to perform some administrative tasks in IIS in order to be able to debug a WebClass. One can delve a bit deeper with help of Process Monitor and API Monitor. It is clear then that VB6.exe relies on COM interfaces of IIS Admin Service. Bad news is that IIS 7+, unlike previous versions, doesn't use Metabase and there is no IIS Admin Service in IIS 7+. One can install IIS Metabase and IIS6 compatibility component that, in theory, should enable applications that use Metabase to continue working with IIS 7+:

Unfortunately, installing it doesn't resolve the problem.

There are suggestions that your problem can be caused by inadequate launch and activation permissions for COM components. I am afraid that all those suggestions are futile. Errors of that kind are always accompanied by related error events in System event log. There are no such events in this case.

Answer 4

Have you considered writing a log file? It's pretty straight forward and you can begin just where the code is most likely to cause an error. I suggest creating a function that takes a few parameters such as a Sub/Function name, an Err object, and an optional extra string so you can include additional information such as what step your code was in. In your error handler call your function passing your parameters.

Answer 5

Man, can I sympathize. I spent almost 3 man-days on this, and still don't have a solution that I'm incredibly happy with, but it does work, so I've "given up" finding the correct solution, and went with this, because I just can't waste any more resource time.

Under IIS Manager, click on virtual directory -> Authentication
- disable anonymous authentication
- enable basic authentication

Browse to app, enter domain or workstation credentials with enough privilege to make the app work based on what is set for the filesystem security where the app lives.

This effectively means that I have to authenticate myself to the virtdir every time I start debugging for the first time, but it's a small price to pay to finally have debugging functional again.