VB6 application won't run in some computers, in others it runs fine

3
votes

I have a VB6 application, the installer is compiled using INNO Setup. The installer runs fine. But in about 10% of computers when the user clicks the Icon to run the installed app, it doesn't start, no error message, only a Beep sound.

This is happening on XP and also Win 7.

I develop in XP and Win 7 and the application works OK, so I haven't been able to reproduce the issue.

The installer registers all ocx and dlls needed (afaik). (Well not completely all, it assumes MS run-time components should be there, but I guess an error message should show up if something is missing)

I was thinking some kind of user permissions, UAC, but even users in the admin group have had the issue.

Could you point me to what possible issues to look for and test in order to patch the app.

Thanks!

[FOLLOW UP]

Thanks to the tips, found out the manifest is causing the problem. I use it to make the controls look better:

http://www.vbaccelerator.com/home/vb/code/libraries/xp_visual_styles/using_xp_visual_styles_in_vb/article.asp

Now I'm trying to discover why. I have another application with the same manifest and that one works ok.

Haven't been able to get feedback on the event viewer yet.

2
vb6runtime-error
You need to make sure all dependecy's are on the destination computer. Have you tried looking in the event viewer to see if an error was logged? I have had issues with the MCI ocx before. – Mark Hall
Is the application an ActiveX EXE? – wqw
wqw: Nope, not an ActiveX Exe. – Sunjen
Mark: ok! will check the event viewer and post back any hints – Sunjen
@Sunjen: Bob's answer looks like the most correct answer here. If you agree, you can accept it as the final answer by clicking the checkmark next to it. For your follow-up, you can start a second question and link back to this one instead of editing this question. You'll get more specific answers that way. – Mike Spross

2 Answers

3
votes

The "beep crash" often points to an error in an application manifest such as an XML syntax error or namspace conflict. Event Logs will often provide a hint about this.

But I've found that people often try to use the Common Controls 6.0 Library without ensuring proper library loading sequence.

Before any Forms are openend you should load shell32 and then comctl32. The easiest way is a couple of no-op calls in Sub Main:

Option Explicit

Private Declare Sub InitCommonControls Lib "comctl32" ()

Private Declare Function IsUserAnAdmin Lib "shell32" () As Long

Private Sub InitCommonControlsVB()
    IsUserAnAdmin
    InitCommonControls
End Sub

Private Sub Main()
    InitCommonControlsVB
    Form1.Show
End Sub

Without this your program will usually work fine in Vista or Win7, but will fail on some XP service pack and patch levels. Part of this is due to changes over time in the Fusion subsystem that handles SxS activation and comctl32.dll patches.

Ignore those saying you need to call InitCommonControlsEx(), it isn't necessary unless you are constructing and using Win32 controls directly instead of VB6 and COM controls.

2
votes

A few things to try to narrow it down:

Check the Windows Event Log for crash events

Check the Windows Event Log (in the Application section) for crash reports from your application. You can quickly get to the log viewer on Windows XP by clicking Start > Run, typing eventvwr and pressing Enter. On Windows 7, you can type "event viewer" in the search box that is in the Start menu. You can filter the events to only show error events from your program.

You might find a few error events on one of the computers where this problem has already occured, because it sounds like the error reporting feature is turned off on these computers (in which case "hard crashes" like access violations are logged in the Event Log instead of displaying an error dialog to the end-user, as long as a debugger isn't installed on the computer).

Make sure "Error Reporting" is turned at the OS level

As mentioned in the previous section, it sounds like the error reporting feature is turned off on these computers. In that case, a crash won't display any kind of message to the end-user at all and the application will just vanish suddenly. In Windows XP, you can check this setting (and turn it on) as follows:

  1. Right-click "My Computer" and select Properties.
  2. Open the Advanced tab and click the Error Reporting button.
  3. Select the Enable Error Reporting option.
  4. Click OK to all the open windows.

Add trace code to your application

You could also add some trace code to your application's start-up code, such as code to display a message box or write a message to the Windows Event Log or to a log file as soon as your application starts (for example, in the Form_Initialize event of your main form, or in a Sub Main routine).

This way you will be able to tell whether your application is crashing before or after the VB6 runtime is loaded: if you try to start the application and it disappears/crashes, and your startup message isn't logged, then you know it's crashing before it even has a chance to get to your application's startup code, which could indicate that a dependency of the VB6 runtime or the VB6 runtime itself is not installed properly.

Note that Windows XP and Windows 7 both ship with the VB6 runtime pre-installed, but it's possible for misbehaving installers to overwrite or remove files that are part of the VB6 runtime.