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 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 2

I think you can be pretty sure it's not an issue that Microsoft doesn't want it to work, but simply that it can't work. Are you aware of this document?: http://msdn.microsoft.com/en-us/vstudio/ms788708.aspx

It states:

The Visual Basic 6.0 IDE has never been offered in a native 64-bit version, nor has the 32-bit IDE been supported on 64-bit Windows. VB6 development on 64-bit Windows or any native architecture other than 32-bit is not and will not be supported.

I've tried as well and failed so opted to run a 32-bit OS in a VM and then it works flawlessly. I think it's due to how the debugger hooks into the kernel to be able to run the debugger.

Answer 3

It sounds like you want the VB6 IDE to fire in the debugger when the app instance is created, and that's failing. Have you tried starting the VB6 IDE in debug mode to host your COM component, set a breakpoint within your source, and then see if accessing the page that uses the component will then cause the breakpoint in the debugger to be hit? That is, take the activation of the VB6 IDE out of the loop - having it running should just cause the CLSID for the app to point to the runtime instance of the IDE as the COM host.

Been a long time since I did dev in VB6, so some of the details may be sketchy, but I do remember that debugging COM servers took some gymnastics, and among one of the solutions was running a separate instance of VB as the COM out-of-process server host.

Answer 4

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.

Answer 5

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 6

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 7

Could you copy the information sent into the VB6 part of the application and test that from the console?

I mean, that's gross, but we are talking about debugging a hybrid IIS VB6 application.

Answer 8

I had this problem today September 14, 2012 and managed to solve it in the simplest way possible, I have debug dlls I need visual basic 6.0 with XP I had no problem but I changed it to windows 7 and there was the problem with iis7, I read in many forums and blogs but nothing I was, even I did this blog, nor, in the end I fixed the problem as follows: Component Services-> Computers-> right Click Properties-> then click the Security tab COM-> section Launch and Activation permissions-> Edit Default -> and then add the Local Service account and gave all permissions. I clarify, for me it worked to debug the dll in visual basic 6.0 locally, but not if it is good or the only solution, I think I did well this should be done over what they say on the other forums , is now well on Microsoft http://support.microsoft.com/kb/899965/es page says the same thing but said that adding the NETWORK SERVICE account as I did and I worked for the mistake that I commanded the event Viewer is:

"Setting permissions set by default on your computer does not grant Local Activation permission to the COM Server application with CLSID {95D14525-F934-4D4F-9B33-2CE753FAF3B0} and APPID {95D14525-F934-4D4F-9B33-2CE753FAF3B0} the user NT AUTHORITY \ LOCAL SERVICE with SID (S-1-5-19) in the address LocalHost (with LRPC). This security permission can be modified using the Component Services administrative tool "

You see says NT \ AUTHORITY \ NETWORK SERVICE LOCAL SERVICE account bone.

Well that's all.

Answer 9

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.