How to Detect What Compoent/Reference causes a Ding When Starting an App

[sweinberger]

Hi All,

There is a computer (Windows 7 64-bit) running my application, and causes the OS to ding whenever a user attempts to load the application. Other computes including my own are fine, even on a clean machine, which I have tested. It seems to me one or more items are either not present, did not load, or whatever on the user’s system.

I created a copy of the application and included all references but none of the source files except for a module containing Main() and inside that a MsgBox call so that I know that the app loaded. That worked. If I include all the source files but the Main() entry point just has the single MsgBox call and nothing else, does not load forms or anything else, the OS dings meaning that it could not find one or more references. The stripped out version without the source files that worked included all component references.

Correct me if I am wrong, but it seems to me that VB6 when it builds the executable only includes a reference into the executable of a Projects | Reference or a Projects | Components if the component is used somewhere, otherwise it does not include the executable reference, even though the project file mentions it. Am I right?

That leads to my question of how do I relatively easily determine which executable reference (VB6’s reference or component) caused the failure upon executable load? One thought that I had is to create what feels like a zillion test applets, one for each reference (VB6 reference or form component) used, but I could still miss something, even if I go through that humongous work, because the OS might be thinking of something that I am not. More so, I am positive that there has to be an easier way to find out which reference causes the build on the user’s machine. I tried VBWatch, a tool that I have to instrument debugging code into the app, but that only takes effect after the executable loads and runs, not before it.

Thanks in advance,

Sarah

[dilettante]

It isn't about "including a reference" as much as it is "loading a library." If you want unused libraries to be ignored (no library loading compiled into the EXE) you'll want to check Remove information about unused ActiveX Controls in the Project Properties.

Even better: remove any library references your Project doesn't use!


The symptoms sound like some sort of SxS configuration problem. Are you attempting to use the 6.0 version of comctl32.dll?

If so you might look at Big problem with manifest/UserControl combination where another issue involved in doing so was confirmed. A program might work fine on some versions of Windows and then fail on another due to small differences in system library versions and the way SxS activation is done.


You might also look for anything logged for the process in the System or Application Event Logs.

[sweinberger]

Hi All,

I had a feeling that I wrote too much. You misunderstand the problem.

I have a program, say, MyProgram.exe. The following steps are taken.

1. Open Windows Explorer and navigate to the folder containing the program.
2. Double click on the executable.
3. (Alternatively, double click on the shortcut)
4. The OS emits a ding, as it tries to load the executable. Executable launch aborted and program never reaches Main().

The problem is obvious. The OS (Windows 7, 64-bit in this case) cannot load one of the dependencies.

My question, how do I track down which dependency the OS has an issue with? I just get a ding, so that is not very helpful.

Thanks,

Sarah

[dilettante]

That's what the "ding" means: a failure occurred when trying to load libraries. Usually in a VB6 program it relates to SxS configuration, such as mismatched versions or multiple versions of the same library (i.e. different SxS assemblies).

I don't think I ever encountered it in any other context. Attempting to use a COM library that isn't present should produce some variation of a "can't create object" exception.

[techgnome]

If the problem is obvious, then so should be the solution - include what ever components you use in the application with your install. Anything that is non-standard should be installed by your installation program. Otherwise, it's not going to work. If you built the program, you should have some idea what components you are using.

-tg

[MartinLiss]

How did the exe get there? In other words did you develop and compile it on the PC, or did you install it, or did you just copy and register files?

[sweinberger]

Obviously and I know the problem.

What I would like to know is a utility that monitors the loading of an application and reports which dependency it cannot find, hence a PE Loader Watcher or something like that. The problem is not VB6 specific. It could be any executable.

Yes, I know which dependencies I include, obviously, but there are a lot of them and I am trying to avoid creating a test applet for each one. I am trying to find a generic PE Loader Watcher.

[dilettante]

You might obtain Dependency Walker 2.2 and run a profile on your program. There is a lot of info there, but the profile log might help you track this down.

Note that most dependencies of a VB6 program are loaded dynamically, which means you won't get much information unless you do a profile run.