App.EXE Won't Run

On Wed, 11 May 2011 15:35:57 -0700, BeeJ wrote:

Now I have several App.EXEs that will not run.
They all run just fine in the IDE.
The crashing app:
Never get to the first line in Sub Main(). e.g. A MsgBox never
shows.
Throw all sorts of error messages that make no sense to me.
Windows Installer
Unexpected Termination

I put Line Numbers in sub Main and an error handler but get the
message from the error code

AppName: Main

Exiting Main: Fatal Error: Line 0

OK


First executable line is 10.


AppName: Log Message

Error: 326

Resource with identifier 'VERSION' not found

OK


AppName: Log Error

Error: 326

Application-defined or object-defined error

OK


Sometimes the App.EXE is left in memory and I use Process Explorer to
close.

ProcMon follows the goings on but I cannot see anything that kills the
app although I do see how MS does some strange and interesting things.

I have the C++ debugger installed and only once did it start but
unfortunately I did not have the symbolic checkbox checked in the IDE
for the compiled code. I do now but it has not generated the same
error.

Other large VB6 apps that I wrote run just fine as an App.EXE.

So the big question is ... What is the difference between running as an
EXE or in the IDE? Where do I find out this information so maybe I can
isolate what some of my apps are doing that Windows or whatever does
not like?

BTW, the other large app that does not run offers absolutely no error
messages.

First off, we need the exact error message/s.

Second the two major differences between a stand-alone exe and running
in the IDE are ...
1) The code is run as excode (executable opcode, aka 'pcode') while
many compiled applications are compiled to native code.
[For grins you might recompile to pcode and run the stand-alone exe.]

2) All external modules/libraries - like ADO, ActiveX Controls or
Dlls, etc. are managed and owned by VBDebug.dll. VB6 retrieves type
information for these items from its own cached 'view' of the
Registery and in the case of a Group compile from local file caches
such as an .oca file.

On occasion, for whatever reason, VB's view of this information may
differ from that of an application running stand-alone. eg, the VBIDE
may be retrieving and loading the 'correct' module, but the
stand-alone using the Windows Loader (sans VBDebug) may be attempting
to load something else.

You didn't say if your Application was using any other VB projects
(eg, a user control). It is always wise to occasionally clean up a
project during long periods of development or after multiple changes
to allow VB to clear its caches and rebuild them.

There are others, but those two are the most important.

Third, VB applications use startup code provide by the VB Runtime. Sub
Main is NOT the main entry point for a VB application. So to put it in
technical terms - a ton of interesting stuff goes on before user code
in either Sub Main or a Form is run, therefore it is quite common for
some fatal errors to occur before you can actually catch the error.

The VC++ debugger is useful, but was not designed for debugging
external startup code. I suggest you install a Just-In-Time Debugger.
I also suggest you install WinDebug.

-ralph