473,326 Members | 2,048 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

Unhandled exception - Different under debugger and non-debugger

I'm getting different behavior if my code is running under the
debugger or not.

I have modified Winmain to look like this:

// Copyright (C) 2002 Microsoft Corporation
// All rights reserved.
// THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF
ANY KIND, EITHER
// EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED
WARRANTIES OF
// MERCHANTIBILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.

// Requires the Trial or Release version of Visual Studio .NET
Professional (or greater).

#include "stdafx.h"
#include "frmMain.h"
#include "MyException.h"

using namespace VCNET;

[System::STAThreadAttribute]
void __stdcall WinMain()
{
try
{
Application::Run(new frmMain());
}
catch (MyException* pMyException)
{
// Show the exception to the user.
MessageBox::Show
(
System::String::Concat
(
MyException->ShowFullMessage(),
S"\r\n\r\n",
S"Internal failure. Program terminates."
),
S"Internal failure. Program terminates.",
MessageBoxButtons::OK,
MessageBoxIcon::Error
);
}
}
In a button handler I throw a MyException.

Under the debugger, the exception is caught in WinMain and a proper
dialog box is displayed.

If I run the executable (either Release or Debugger builds) then the
exception is not caught and the system displays an unhandled exception
message. The unhandled message displays the proper information.stored
in the MyException object.

Admittedly, the exception is being thrown from a function thirty levels
of procedure call between the function and WinMain() through a bunch of
system dlls.

Nonetheless, I would not expect different behavior if the program is
running under the debugger and without the debugger.

Nov 17 '05 #1
9 2283
I have found if you change:

int __stdcall WinMain(void)

as the 'main' call format to:

int _tmain(void)

that the exception goes away for me. BUT, this brings up the black Console
screen, which I need to eliminate. So I have the problem (in my case)
half-solved... : )

[==P==]
"RalphTheExpert" <ra****@dos32.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...
I'm getting different behavior if my code is running under the
debugger or not.

I have modified Winmain to look like this:

// Copyright (C) 2002 Microsoft Corporation
// All rights reserved.
// THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF
ANY KIND, EITHER
// EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED
WARRANTIES OF
// MERCHANTIBILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.

// Requires the Trial or Release version of Visual Studio .NET
Professional (or greater).

#include "stdafx.h"
#include "frmMain.h"
#include "MyException.h"

using namespace VCNET;

[System::STAThreadAttribute]
void __stdcall WinMain()
{
try
{
Application::Run(new frmMain());
}
catch (MyException* pMyException)
{
// Show the exception to the user.
MessageBox::Show
(
System::String::Concat
(
MyException->ShowFullMessage(),
S"\r\n\r\n",
S"Internal failure. Program terminates."
),
S"Internal failure. Program terminates.",
MessageBoxButtons::OK,
MessageBoxIcon::Error
);
}
}
In a button handler I throw a MyException.

Under the debugger, the exception is caught in WinMain and a proper
dialog box is displayed.

If I run the executable (either Release or Debugger builds) then the
exception is not caught and the system displays an unhandled exception
message. The unhandled message displays the proper information.stored
in the MyException object.

Admittedly, the exception is being thrown from a function thirty levels
of procedure call between the function and WinMain() through a bunch of
system dlls.

Nonetheless, I would not expect different behavior if the program is
running under the debugger and without the debugger.

Nov 17 '05 #2
My guess is that the console screen comes up because you have specified
that the linker option, subsystem, is console rather than than windows.

If the program is console then the envirnoment is much simpler and
there are likely far fewer dlls between a throw and the catch.
I vaguely remember haveing the same problem in VC 6. If my memory is
correct, it was bad to attempt to do a throw from inside of a message
pump to outside of one.
I know fairly little of the internals of MC++ in a /subsystem:windows
environment. I'm not even sure if there is a message pump.

Nonetheless, I'd sure like to know if it is legal to do a throw from
inside a message handler all the way out to WinMain.

Nov 17 '05 #3
I checked, and it was at 'Not Set'. When I set it to /SUBSYSTEM:WINDOWS it
will give me a compiler error unless I use int __stdcall WinMain(void) as
the 'main' call to the application, in which case it doesn't bring up the
Console but does exit with an exception error. If I set it to
/SUBSYSTEM::CONSOLE I get a compiler error unless I use int _tmain(void) as
the 'main' call to the application, in which case it brings up the Console
and there is no exception error on exit.

Thus, it behaves no different than if I left it to 'Not Set' and just
changed the form of the 'main' call. I can think of no good reason that a
program should produce an exception error (you know, the kind that brings up
the 'do you want to send this problem to MS for analysis?' dialog box)
UNLESS its uses a Console. This probably means the problem isn't in my
application code, but in some setup of the project. Since this didn't happen
in 2003, how in hell am I suppose to find out what is causing the exception
(the info it spits out is of no apparent help, it just says it got an
exception error and exits with code: -1073740791 (0xc0000409). Oh goody,
isn't that helpful? ; )

One thought. I allowed 2005 to convert my application from 2003 to 2005.
When I did this with a project from 2002 to 2003 it turned out the
conversion was not entirely successful, and 3 weeks later I ran into a bug
that could only be fixed by opening up a new 2003 project and copying the
source over form the previous project (it kept telling me I was using an
out-dated version in the Linker, but the interesting part is that this
warning only started happening weeks after I did the conversion, during
which time I did EXTENSIVE changes and additions to the code). Is it
possible the 2003 to 2005 conversion also has problems?

[==P==]

"RalphTheExpert" <ra****@dos32.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...
My guess is that the console screen comes up because you have specified
that the linker option, subsystem, is console rather than than windows.

If the program is console then the envirnoment is much simpler and
there are likely far fewer dlls between a throw and the catch.
I vaguely remember haveing the same problem in VC 6. If my memory is
correct, it was bad to attempt to do a throw from inside of a message
pump to outside of one.
I know fairly little of the internals of MC++ in a /subsystem:windows
environment. I'm not even sure if there is a message pump.

Nonetheless, I'd sure like to know if it is legal to do a throw from
inside a message handler all the way out to WinMain.

Nov 17 '05 #4
"RalphTheExpert" <ra****@dos32.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...
I'm getting different behavior if my code is running under the
debugger or not.

I have modified Winmain to look like this:
[snipped code]
In a button handler I throw a MyException.
There's your problem. It's undefined whether an event that's raised in a
window message handler will propagate out to the message loop (or the caller
of the message loop in your case).

Under the debugger, the exception is caught in WinMain and a proper
dialog box is displayed.

If I run the executable (either Release or Debugger builds) then the
exception is not caught and the system displays an unhandled exception
message. The unhandled message displays the proper information.stored
in the MyException object.

Admittedly, the exception is being thrown from a function thirty levels
of procedure call between the function and WinMain() through a bunch of
system dlls.

Nonetheless, I would not expect different behavior if the program is
running under the debugger and without the debugger.


The debugger is very intimately involved in propagation and handling of
exception when attached, so I'm not too surprised that there's a difference
in behavior.

-cd
Nov 17 '05 #5
Carl:

As I had written in another eMail: "I vaguely remember haveing the same
problem in VC 6. If my memory is correct, it was bad to attempt to do a
throw from inside of a message pump to outside of one."

I'd like to ask two related questions.

(1) Why is the behavior undefined and where is it written that it is
undefined?

(2) What's the proper way to take care of an exception in a message
handler? How can one propagate the error out of a message handler?

--
Sent via .NET Newsgroups
http://www.dotnetnewsgroups.com
Nov 17 '05 #6
RalphTheExpert wrote:
Carl:

As I had written in another eMail: "I vaguely remember haveing the
same problem in VC 6. If my memory is correct, it was bad to attempt
to do a throw from inside of a message pump to outside of one."

I'd like to ask two related questions.

(1) Why is the behavior undefined and where is it written that it is
undefined?
I wish I had a good answer. I got that answer in the kernel group, from
Ivan Bruglio of Microsoft. It's basically just not supported by
User32.dll - it might work, it might not.
(2) What's the proper way to take care of an exception in a message
handler? How can one propagate the error out of a message handler?


I would think the only fully sanitary, guaranteed to work way would be to
either terminate the program from inside the handler, or intern the
exception in an object and pass (a pointer to) that object through a WM_APP
window message where your message loop can unwrap it and re-throw or
otherwise handle the exception.

-cd
Nov 17 '05 #7
I'm getting different behavior if my code is running under the
debugger or not.
...
In a button handler I throw a MyException.

Under the debugger, the exception is caught in WinMain and a proper
dialog box is displayed.

If I run the executable (either Release or Debugger builds) then the
exception is not caught and the system displays an unhandled exception
message. The unhandled message displays the proper information.stored
in the MyException object.


The difference in behavior is because WinForms uses different window procedures
when running under debugger and without debugger. The one used under debugger
allows exceptions to propagate, the one used without debugger catches and reports
them. It can be changed in the application's .config file:
http://support.microsoft.com/default...b;en-us;836674

Regards,
Oleg
[VC++ MVP]

Nov 17 '05 #8
(1) Why is the behavior undefined and where is it written that it is
undefined?


I wish I had a good answer. I got that answer in the kernel group, from
Ivan Bruglio of Microsoft. It's basically just not supported by
User32.dll - it might work, it might not.


I believe it applies to native C++ exceptions, and the problem is that these exceptions
are described with a set of data structures, which are (can be) specific
to a particular version of CRT. When a module throws a C++ exception and
another module, linked with a different version of CRT, tries to analyze its decription
(to determine its type and decide whether it should be handled), the difference
in the exception description formats can lead to unpredictable results.

Regards,
Oleg


Nov 17 '05 #9
Oleg and Carl:

I am continuing this thread in a new thread:

BUG: An exception does not propagate correctly to the calling function
in a Windows Forms application project in Visual Studio .NET

Ralph Shnelvar

--
Sent via .NET Newsgroups
http://www.dotnetnewsgroups.com
Nov 17 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

4
by: Anders Borum | last post by:
Hello! I am working on improving my threading skills and came across a question. When working with the ReaderWriterLock class, I am getting an unhandled exception if I acquire a WriterLock with...
2
by: Colin Thomsen | last post by:
I have a native VC++ application which runs differently (incorrectly) if the .NET framework is installed. A trimmed version of the app is shown below. The intention is for the SEHHandler to...
7
by: Chuck Hartman | last post by:
I have a Windows service that requests web pages from a site using an HttpWebRequest object. When I try to request a page from an ASP.NET 2 site, I get a WebException with message "The remote...
5
by: Dave Stewart | last post by:
I recently wrote my first Vb.net application, or at least my first complex app since moving up from vb6. When run from the VS.NET IDE, the program shows no errors and runs fine. When the output exe...
5
by: Lucvdv | last post by:
Can someone explain why this code pops up a messagebox saying the ThreadAbortException wasn't handled? The first exception is reported only in the debug pane, as expected. The second (caused by...
5
by: mattiassich | last post by:
The following code causes unhandled exception on the line: New ManagementObjectSearcher(query) Dim mos As System.Management.ManagementObjectSearcher Dim moc As...
0
by: Colmeister | last post by:
I recently read Jason Clark's excellent article on Unhandled Exceptions (http://msdn.microsoft.com/msdnmag/issues/04/06/NET/default.aspx) and have attempted to incorporate the features he talks...
5
by: Simon Tamman {Uchiha Jax} | last post by:
Now this is bugging me. I just released software for a client and they have reported an unhandled stack overflow exception. My first concern is that the entirity of the UI and any threaded...
3
by: Andreas van de Sand | last post by:
Hi everyone, I've got an application which uses a custom exception handler and to avoid unhandled exceptions I've got a try{}catch (Exception){} block around the main Application.Run(...). ...
0
by: Mike S | last post by:
I'm still looking into this problem, but to summarize: I wrote a very simple Windows Service in VB.NET, as part of a larger application. I created a deployment project for the application the...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.