Trapping Windows Error

[Ivar]

Hi All.

Here's hoping the VB6 gurus are still monitoring this newsgroup.
I recently updated an app of mine and distributed it to the end users.
A Couple of users have reported a problem where the app will stop working
and a message comes up with:
ProgName has encountered a problem and has to close
Windows is searching for a solution.
I can't replicate this problem on any machine I have access to, but I'm
fairly sure it's when the app calls the 'FreeLibrary' API of "kernel32"
Because it seems to work for most users, I'm assuming some users have a
broken Kernel32.DLL

Is it possible for a VB6 app to handle this kind of error?
And of course, If so, How?

Thanks for any pointers.

Ivar

[ralph]

On Sun, 9 Dec 2012 08:14:31 -0000, "Ivar"

Post by Ivar
Hi All.
Here's hoping the VB6 gurus are still monitoring this newsgroup.
I recently updated an app of mine and distributed it to the end users.
A Couple of users have reported a problem where the app will stop working
ProgName has encountered a problem and has to close
Windows is searching for a solution.
I can't replicate this problem on any machine I have access to, but I'm
fairly sure it's when the app calls the 'FreeLibrary' API of "kernel32"
Because it seems to work for most users, I'm assuming some users have a
broken Kernel32.DLL
Is it possible for a VB6 app to handle this kind of error?
And of course, If so, How?
Thanks for any pointers.
Ivar

Highly improbable that your Users have a "broken Kernel32.DLL". If
they did - they would be having a lot more issues than just with your
program.

Due to configuration differences and complexities of Windows
platforms, it is entirely possible while invoking an external process
or service to have success in one scenario, yet fail, with or without
error, in another.

As for capturing the error - assuming it is in fact your application
that is throwing the error, and that it is happening past 'startup' or
launch, then simply reengineer your application to not have any
unhandled exceptions, ie provide at least a "top" error handler for
all possible paths. This is seldom as time consuming nor complicated
as it might first appear.

[Tools such as MZ-Tools makes this instrumentation easier.]

Another way to get more accurate information on where an error is
coming from is to enable Dr. Watson - if Users are using Windows XP or
below. Or perhaps getting the Users to install and enable WinDbg if
using Vista or Windows 7/8.

-ralph

[Ivar]

Hi Ralph

Thank you for your reply.
I sent my client a new exe file with the FreeLibrary call commented out and
app does not stop working.
So I'm sure it's that API call that's causing the problem
I have some old sample code that calls some API functions (probably from
PSC) Where if I run it from within the IDE Then it will cause VB6 to stop
working and freeze with the same 'ProgName has stopped working' windows
message, with a progress doing it's thing, and if I run it as a compiled exe
it will do the same thing (ProgName changes obviously)
After clicking the Cancel button the complied exe or VB6 will just close.
'On Error Resume Next' or 'On Error GoTo' makes no difference when running
this sample code as compiled exe or within VB6 IDE.

It's Not a run time error . My App seems to run quite happily with this
FreeLibrary call on all but 2 machines (Both running Windows 7, but so are
others)
I'm thinking that Any App (even VB6 itself) cannot handle this kind of
error.
Still hoping someone can prove me wrong :-)

Ivar

[Deanna Earley]

Post by Ivar
Hi Ralph
Thank you for your reply.
I sent my client a new exe file with the FreeLibrary call commented out
and app does not stop working.
So I'm sure it's that API call that's causing the problem
I have some old sample code that calls some API functions (probably from
PSC) Where if I run it from within the IDE Then it will cause VB6 to
stop working and freeze with the same 'ProgName has stopped working'
windows message, with a progress doing it's thing, and if I run it as a
compiled exe it will do the same thing (ProgName changes obviously)
After clicking the Cancel button the complied exe or VB6 will just close.
'On Error Resume Next' or 'On Error GoTo' makes no difference when
running this sample code as compiled exe or within VB6 IDE.
It's Not a run time error . My App seems to run quite happily with this
FreeLibrary call on all but 2 machines (Both running Windows 7, but so
are others)
I'm thinking that Any App (even VB6 itself) cannot handle this kind of
error.
Still hoping someone can prove me wrong :-)

C++ apps can handle exceptions (if they're careful) but VB6 apps can't
(easily).
FreeLibrary itself is unlikely to be the cause of an unhandled exception
(as they aren't common in Win32) but it could be caused by any DLL or
process hooked into it, i.e antivirus, etc, or just some code related to
the FreeLibrary call in your code that is faulty.

Your only hope to fix it properly is to get a full error message with
the exception code.
This will be listed in the event viewer and sometimes in the WER crash
dialog itself.

[Tim Rude]

Post by Ivar
Hi Ralph
Thank you for your reply.
I sent my client a new exe file with the FreeLibrary call commented out
and app does not stop working.

Try sending the client an exe with the FreeLibrary call (not commented out)
preceeded by 'On Error Resume Next'. Immediately after the FreeLibrary call
line, add: MsgBox "Program execution continues"

If the app runs without crashing and your user gets the messagebox popup,
that tells you that VB can handle (either trap and deal with or else ignore)
this errror. Then it's up to you how to best handle it within VB.

If the program crashes and the messagebox doesn't pop up, then you may have
something VB can't deal with (seems unlikely).

[Ivar]

Hi Tim

The Program does not 'Crash', It stops execution, Fades out a bit and the
windows dialog does it's thing until the user clicks Cancel or windows
generates 2 or 3 text files that invites you to send to Microsoft. Then the
app will just end.
On Error Resume Next and On Error GoTo does nothing because the app itself
does not error.

Ivar

Post by Ivar
Hi Ralph
Thank you for your reply.
I sent my client a new exe file with the FreeLibrary call commented out
and app does not stop working.

Try sending the client an exe with the FreeLibrary call (not commented out)
preceeded by 'On Error Resume Next'. Immediately after the FreeLibrary call
line, add: MsgBox "Program execution continues"

If the app runs without crashing and your user gets the messagebox popup,
that tells you that VB can handle (either trap and deal with or else ignore)
this errror. Then it's up to you how to best handle it within VB.

If the program crashes and the messagebox doesn't pop up, then you may have
something VB can't deal with (seems unlikely).

[Tim Rude]

Post by Ivar
Hi Tim
The Program does not 'Crash', It stops execution, Fades out a bit and the
windows dialog does it's thing until the user clicks Cancel or windows
generates 2 or 3 text files that invites you to send to Microsoft. Then
the app will just end.
On Error Resume Next and On Error GoTo does nothing because the app itself
does not error.
Ivar

Well then, maybe you're attempting to unload something you shouldn't be
unloading at that point. Maybe it's something your VB app still needs. It
kinda sounds like your kicking the legs out from under it.

[Deanna Earley]

Post by Ivar
Hi Tim
The Program does not 'Crash', It stops execution, Fades out a bit and
the windows dialog does it's thing until the user clicks Cancel or
windows generates 2 or 3 text files that invites you to send to
Microsoft. Then the app will just end.

That's a crash.

Post by Ivar
On Error Resume Next and On Error GoTo does nothing because the app
itself does not error.

Just not one you can handle after it's occurred.

[Karl E. Peterson]

Post by Deanna Earley

Post by Ivar
Hi Tim
The Program does not 'Crash', It stops execution, Fades out a bit and
the windows dialog does it's thing until the user clicks Cancel or
windows generates 2 or 3 text files that invites you to send to
Microsoft. Then the app will just end.

That's a crash.

Post by Ivar
On Error Resume Next and On Error GoTo does nothing because the app
itself does not error.

Just not one you can handle after it's occurred.

Could set a GPF hook, no? I'd hafta look it up, but I'm sure I (or
someone I was working with <g>) wrote a column about that at one point.

[Deanna Earley]

Post by Karl E. Peterson

Post by Deanna Earley

Post by Ivar
Hi Tim
The Program does not 'Crash', It stops execution, Fades out a bit and
the windows dialog does it's thing until the user clicks Cancel or
windows generates 2 or 3 text files that invites you to send to
Microsoft. Then the app will just end.

That's a crash.

Post by Ivar
On Error Resume Next and On Error GoTo does nothing because the app
itself does not error.

Just not one you can handle after it's occurred.

Could set a GPF hook, no? I'd hafta look it up, but I'm sure I (or
someone I was working with <g>) wrote a column about that at one point.

I know you can delve into Win32 (I did allude to this earlier) to handle
it but I wouldn't like to guarantee the stability of the VB runtime to
do anything more then log and exit.

A far easier fix is to get the crash dump and find/fix the real cause :)

[Jim Mack]

Post by Ivar
I sent my client a new exe file with the FreeLibrary call commented out
and app does not stop working.
So I'm sure it's that API call that's causing the problem

I don't know what the conventional wisdom is, but I doubt there's any
benefit to calling FreeLib on a common system library. Trust me: you
aren't going to unload it. (-:

--
Jim

[Ivar]

Hi Jim

but I doubt there's any benefit to calling FreeLib on a common system
library.

I didn't say it was a common system library (and it isn't)
Corse you can, been there, seen it, done it. There's even examples of
loading and unloading system libraries in the API guide.
It's called explicit linking.

Thanks anyway :-)

Ivar

--
Jim

[Jim Mack]

Post by Ivar
Hi Jim

but I doubt there's any benefit to calling FreeLib on a common system
library.

I didn't say it was a common system library (and it isn't)
Corse you can, been there, seen it, done it. There's even examples of
loading and unloading system libraries in the API guide.
It's called explicit linking.

I'm well aware of the concept, but your mention of kernel32 led me to
believe that's the lib you were invoking. I would never call
FreeLibrary on a system DLL.

--
Jim

[Ivar]

Post by Jim Mack
I'm well aware of the concept, but your mention of kernel32 led me to
believe that's the lib you were invoking. I would never call FreeLibrary on
a system DLL.

Hi Jim

I see your point.
I'm calling the FreeLibrary of Kernel32. Not Trying To Free Kernel32.
It seems Kernel32 references other System Libraries, may be the error lies
in a referenced library.
It really seems there is no way to catch an error like this.
Thanks for your replies.

Ivar

[Thorsten Albers]

Post by Ivar
I see your point.
I'm calling the FreeLibrary of Kernel32. Not Trying To Free Kernel32.
It seems Kernel32 references other System Libraries, may be the error lies
in a referenced library.
It really seems there is no way to catch an error like this.
Thanks for your replies.

So which library is it which you want to free with FreeLibrary()?

It is for 100% sure that it is not the call to FreeLibrary() itself which
causes the crash. This kernel function is called thousands of times a
'usual' computer working day. If it would fail, Windows would.
If your application crashes because it calls FreeLibrary() the reason for
the crash must be within the library which shall be freed, or a library
referenced by it.

[Jim Mack]

Post by Ivar
I'm calling the FreeLibrary of Kernel32. Not Trying To Free Kernel32.
It seems Kernel32 references other System Libraries, may be the error
lies in a referenced library.

Kernel32 is already linked by the VB6 runtime. An extra LoadLib is
really doing nothing except giving you an entry point -- it does not
actually load another kernel32. So calling FreeLib is probably not
doing what you expect. As I said, I'd never do that.

Of course, sequence matters. If K32 has not yet been invoked by the VB6
RT when you do your LoadLib, calling FreeLib afterward might actually
cause harm.

--
Jim

[Ivar]

Hi Jim.

Honest honest honest I am not loading or unloading K32 (or any other system
file)
I have a few API decs that reference some of K23s various functions, One
being LoadLibrary and One Being FreeLibary.
I Load a third party DLL at run time, That works just fine, I call it's
functions that I need, all works well. Then my app unloads it when no longer
needed. That bit seems to work flawlessly on most PCs but not all. A couple
report this problem.
It's seems the only solution to this prob is to leave the dll loaded
One thought that I have is that the FreeLibrary is called to soon, The DLL
is still doing it's thing when FreeLibrary is called.
I could inset a sleep or something.
But I can't test this without really annoying some people that I would
prefer to keep happy.

Thanks

Ivar

[Jim Mack]

Post by Ivar
Hi Jim.
Honest honest honest I am not loading or unloading K32 (or any other
system file)
I have a few API decs that reference some of K23s various functions, One
being LoadLibrary and One Being FreeLibary.
I Load a third party DLL at run time, That works just fine, I call it's
functions that I need, all works well. Then my app unloads it when no
longer needed. That bit seems to work flawlessly on most PCs but not all.
A couple report this problem.

Then the solution is to not call FreeLib. The DLL will be released when
your program exits, so there's usually no reason to unload.

--
Jim

[Ivar]

Post by Jim Mack
Then the solution is to not call FreeLib. The DLL will be released when
your program exits, so there's usually no reason to unload.

Hi Jim

I agree, but that's not the solution, that's a cop out being so the original
question was about trapping the error. And there does not seem to be a way
of doing that because the error is not within the app itself :-(
I'm using Windows 7 Home Premium with VB6. all service packs installed. Try
This:
In VB6 IDE have one code window open.
Highlight a small bit of text (Like 'End If') and ask VB to 'Find Next' text
in the current module once only
Close The Code window so that no code is showing in the IDE but the find
dialog is still up.
Click the 'Find Next' button again. (Yes I know it's a silly thing to do :-)
My VB will always Freeze, fade out a bit and the Windows Program Error
Dialog comes up.
That's the kind of error being reported to me.
Do you get the same results.? Just curious

Ivar

[RW]

On Tue, 11 Dec 2012 05:39:56 -0000, "Ivar"

Post by Ivar
In VB6 IDE have one code window open.
Highlight a small bit of text (Like 'End If') and ask VB to 'Find Next' text
in the current module once only
Close The Code window so that no code is showing in the IDE but the find
dialog is still up.
Click the 'Find Next' button again. (Yes I know it's a silly thing to do :-)
My VB will always Freeze, fade out a bit and the Windows Program Error
Dialog comes up.
That's the kind of error being reported to me.
Do you get the same results.? Just curious

FWIW I just tried your experiment (VB6 SP6 Win7 Pro 64x).
All that happened was the Find Next button became disabled (greyed
out). Clicking Cancel closed the Find dialog and I was still in the
IDE with the form window displaying the form, and the IDE was still
running fine.

[Ivar]

Post by RW
FWIW I just tried your experiment (VB6 SP6 Win7 Pro 64x).
All that happened was the Find Next button became disabled (greyed
out). Clicking Cancel closed the Find dialog and I was still in the
IDE with the form window displaying the form, and the IDE was still
running fine.

And Just How bizarre is that? The Find Next button being disabled is exactly
what you would expect to happen. But not on my development machine.
Just goes to show that different things can happen on different computers.
Thanks for the input

Ivar

[Deanna Earley]

Post by Ivar

Post by RW
FWIW I just tried your experiment (VB6 SP6 Win7 Pro 64x).
All that happened was the Find Next button became disabled (greyed
out). Clicking Cancel closed the Find dialog and I was still in the
IDE with the form window displaying the form, and the IDE was still
running fine.

And Just How bizarre is that? The Find Next button being disabled is
exactly what you would expect to happen. But not on my development machine.
Just goes to show that different things can happen on different computers.
Thanks for the input

Or service pack.
Make sure you have SP6 before trying to report any bugs in the IDE/runtimes.

[Thorsten Albers]

Post by Ivar
I agree, but that's not the solution, that's a cop out being so the original
question was about trapping the error.

Try SetErrorMode() with SEM_NOGPFAULTERRORBOX. Exp.:

PrevErrorMode = SetErrorMode(SEM_NOGPFAULTERRORBOX)
Call FreeLibrary(...)
SetErrorMode(PrevErrorMode)

Maybe this will catch the error.

Post by Ivar
And there does not seem to be a way
of doing that because the error is not within the app itself :-(

The error is within the app itself in that the app uses a library which
obviously is free of errors!

[GS]

Ivar,
I was going to interject what Jim says here. My apps run reg-free via
LoadLibrary() and since the DLLs run InProcess, they get freed when the
app quits.

[David Kerber]

In article <c1lxs.804333$A%***@fx26.am4>, ivar.ekstromer000
@ntlworld.com says...

Post by Ivar
Hi Ralph
Thank you for your reply.
I sent my client a new exe file with the FreeLibrary call commented out and
app does not stop working.
So I'm sure it's that API call that's causing the problem

Permissions? Some users running as administrator, and others not?