Re: .NET CLR exceptions reported but debugger does not break on them - DOTNET
This is a discussion on Re: .NET CLR exceptions reported but debugger does not break on them - DOTNET ; "Alex Kravchenko" <alexk@newsgroups.nospam> wrote in message
news:CE0B106E-0F46-4DC9-BBA2-ABBBA378A760@microsoft.com...
>I am investigating a problem with a Windows service process, which
> continuosly throws .NET CLR exceptions which are reported by the
> Performance
> Counter viewer tool (counter is "# of Exceps ...
-
Re: .NET CLR exceptions reported but debugger does not break on them
"Alex Kravchenko" <alexk@newsgroups.nospam> wrote in message
news:CE0B106E-0F46-4DC9-BBA2-ABBBA378A760@microsoft.com...
>I am investigating a problem with a Windows service process, which
> continuosly throws .NET CLR exceptions which are reported by the
> Performance
> Counter viewer tool (counter is "# of Exceps Thrown", object is ".NET CLR
> Exceptions"). The approximate rate is 20 exceptions/minute.
> The problem is that I did not manage to make the Visual Studio 2005
> debugger
> to break an execution of the program on an exception thrown.
> I did have all debug symbol files for all managed modules, and set the
> debugger to break on any exception thrown after attaching it to the
> process.
> The host process is unmanaged executable that loads some managed .NET 2.0
> code on startup.
> I s there is another way to trace the source of the exceptions thrown in
> the
> process?
>
In Visual Studio, go to Debug/Exceptions and choose to break when CLR
exceptions are thrown. The default is to break only on unhandled
exceptions.
David
-
Re: .NET CLR exceptions reported but debugger does not break on th
Hi Alex,
The "# of Exceps Thrown" performance counter will report the number of
exceptions thrown. However, the thrown exceptions may be expected and
caught by other .Net code. If the exception is caught by .Net code, it is
not considered as a problem, but as an expected normal code path. For
example, you may call some file I/O methods to access certain files on
disk; However, the files do not exist on the disk, so the .Net Base Class
Library methods normally throw an FileNotFoundException to indicate the
failure. I think your application is robust enough and handles this
exception, because this exception is expected and application is not fail.
Win32 API normally uses return value to indicate the calling failure, while
Net methods use exceptions to indicate the failure. So thrown exceptions
in .Net process is a normal behavior. Only the exceptions that are not
handled by any code are really application failure or crash. For this
reason, debugger will only break for the unhandled exceptions thrown in a
process. For the handled exceptions(called first chance exception in
debugger world), they are considered expected and known to the developers,
so debuggers will not break.
However, debuggers really display a notification message for the first
chance exception(handled exception). The first chance notification message
is displayed in "Output" window while debugging. Can you open "Output"
window in VS2005 debugger during debugging and check if any message is
appended?
I have written a sample application to throw exceptions, see code below:
namespace ExceptTest
{
class Program
{
static void Main(string[] args)
{
for (int j = 0; j < 1000; j++)
{
for (int i = 0; i < 10000; i++)
{
try
{
throw new Exception("abc");
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
}
}
System.Threading.Thread.Sleep(100);
}
}
}
}
While debugging this application in VS2005, I will get the first chance
exception notification message below:
"A first chance exception of type 'System.Exception' occurred in
ExceptTest.exe"
Once you can identify the exception type in your service application, you
may config the Debug/Exceptions dialog to break for the first chance
exception. Maybe a customized CLR exception should be added to the dialog.
Finally, I assme these exceptions are thrown by your specific service
application, because I tried to monitor a trivial sample .Net Service
application, the "# of Exceps Thrown" counter is always zero.
I will wait for your further information. Thanks.
Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project ****ysis and dump ****ysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
-
Re: .NET CLR exceptions reported but debugger does not break on th
> The result of test on Windows Server 2003 machine is the same - .NET CLT
> exceptions counter is incrementing, but debugger does not trap them.
>
Try to disable Just My Code debugger feature - will it help?
Tools | Options | Debugging | General | Enable Just My Code
Also, make sure that you select the managed debug engine
when attaching to the process ("Select" button in Attach to Process dialog)
--
Oleg
[VC++ MVP http://www.debuginfo.com/]
-
Re: .NET CLR exceptions reported but debugger does not break on th
Yes, That was it!
Disabling "Just My Code" feature made the debugger trapping the exceptions.
Apparently System.Runtime.SerilizationExceptions were raised by the
mscorlib.dll when failing to serialize objects hosted by the process being
debug. The exceptions were thrown on one of the threads that was originated
in the code that did not have debug symbols loaded. That is probably why the
debugger was ignoring them...
Thank you for you help,
Alex.
"Oleg Starodumov" wrote:
>
> > The result of test on Windows Server 2003 machine is the same - .NET CLT
> > exceptions counter is incrementing, but debugger does not trap them.
> >
>
> Try to disable Just My Code debugger feature - will it help?
> Tools | Options | Debugging | General | Enable Just My Code
>
> Also, make sure that you select the managed debug engine
> when attaching to the process ("Select" button in Attach to Process dialog)
>
> --
> Oleg
> [VC++ MVP http://www.debuginfo.com/]
>
>
>
>
-
Re: .NET CLR exceptions reported but debugger does not break on th
Hi Alex,
Thank you sharing the result with us!
It seems my VS2005 debugger always unchecks the "Just My Code" option and
has the "Tools"->Options->Debugging->Symbols setting to the symbol server.
So I always have the debugging symbols loaded for .Net FCL assemblies which
makes me neglect the JMC option for you. Sorry for overlooking this.
The blog entry below provide more information regarding "Just My Code". The
most interesting thing is which code the debugger does not consider as
"your code":
1. If the code is compiled optimized, it is not your code
2. If you don't have symbols, it is not your code
"Is 'Just my Code' for you?"
http://blogs.msdn.com/greggm/archive...29/201315.aspx
Also, as you can see, as a hard core developer, we are recommended to turn
off this future in daily work and I really turn-off JMC for all my VS2005
debuggers(although the symbol loading may hurts some performance).
If you still need any help or have any concern, please feel free to tell
me, thanks.
Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project ****ysis and dump ****ysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Similar Threads
-
By Application Development in forum DOTNET
Replies: 0
Last Post: 11-09-2007, 04:47 PM
-
By Application Development in forum CSharp
Replies: 2
Last Post: 09-23-2007, 04:47 AM
-
By Application Development in forum CSharp
Replies: 0
Last Post: 08-14-2007, 03:05 PM
-
By Application Development in forum Inetserver
Replies: 1
Last Post: 01-20-2007, 12:02 AM
-
By Application Development in forum Adobe Indesign
Replies: 4
Last Post: 12-21-2006, 06:59 PM