I am compiling a project using csc.exe, with the /analyzer: flag pointing to the paths of ErrorProne.Net.CoreAnalyzers.dll and ErrorProne.Net.Core.dll, which are built from my clone of the library here.
However, I see several error messages like these:
"warning CS8032: An instance of analyzer
ErrorProne.NET.AsyncAnalyzers.ConcurrentCollectionAnalyzer cannot be
created from
C:\Repos\RoslynExample\RoslynExample\ErrorProne.Net.CoreAnalyzers.dll
: Exception has been thrown by the target of an invocation."
"warning CS8032: An instance of analyzer
ErrorProne.NET.AsyncAnalyzers.AddConfigureAwaitAnalyzer cannot be
created from
C:\Repos\RoslynExample\RoslynExample\ErrorProne.Net.CoreAnalyzers.dll
: Exception has been thrown by the target of an invocation."
etc.
I would like to get more debug information, so that I know exactly when and where these errors are thrown, as well as their inner exceptions. As of now, these error messages on their own are useless.
It is important that I am able to print the stack traces (especially the inner exceptions) to console, or write it to file.
How can I get a copy of the stack trace?
UPDATE:
I figured out the cause of these errors by 1) creating a console application which runs the analyzers built from my clone of the Error.Net source code, 2) disabling Just My Code, and 3) breaking on all exceptions. While it is great to finally figure out what the problem is, it still leaves my original question unanswered: How can I get access to the inner exceptions (so that I can display them later) just by running csc.exe?
did you try to turn on Trace output?
csc -r:System.dll -d:TRACE -d:DEBUG=FALSE MyApplication.cs
Maybe this article will be usefull for you How to: Compile Conditionally with Trace and Debug
Related
I have a WPF application that has started failing with the following error at start:
System.InvalidOperationException: ''{DependencyProperty.UnsetValue}' is not a valid value for property 'BorderBrush'.'
This exception was originally thrown at this call stack:
[External Code]
This is not very forthcoming about what has caused the error. I have tried turning on the CLR Exceptions and restarting as per This Page, but it did not give any more information; I turned on the disassembly, but don't understand what it means. Turning on "Just My Code" debugging and all the Exception Settings as per this page got slightly more in the exception stack trace:
System.InvalidOperationException
HResult=0x80131509
Message='{DependencyProperty.UnsetValue}' is not a valid value for property 'BorderBrush'.
Source=WindowsBase
StackTrace: at System.Windows.DependencyObject.GetEffectiveValue(EntryIndex entryIndex, DependencyProperty dp,
RequestFlags requests)
This exception was originally thrown at this call stack:
System.Windows.DependencyObject.GetEffectiveValue(System.Windows.EntryIndex, System.Windows.DependencyProperty, System.Windows.RequestFlags)
but none of this gives me (that I can see) any information about what code is failing. I have got down to deleting various bits and re-starting the app, but it is extremely time-consuming and I can't help but wonder - is there something else I should be doing.
Is there any way I can find out which bit of code is failing, or any clues (e.g. search terms to look for in my code, clues as to whether it would be a .xaml or a .cs page, places to look in the Exception details, anything) that might help narrow down the location? For instance, is this something that would only be returned by a failed attempt to override the template defaults in wpf, or might it be caused by one of my windows - Is it likely to have come from a style maybe?
Basically, other than seeing that there seems to be a place where I should be setting the BorderBrush and am not, I have no idea how to find what error I need to fix - and since it is a missing thing, I don't know how to find it. Any leads, hunches or advice will be greatly received!
This is a WPF Windows Application, writing in Visual Studio 2019 using .NET 4.8
So it turns out that there really is no way to find out clearly where the error was, but through a process of deleting files, clearing out references and reinstating, I was able to find the problem.
There was a reference to a static resource in a connected .DLL that no longer existing since the .DLL was republished without checking. The change in name there meant that a resource was not found and the unset value was sent to the Dependency Property. It would be lovely if Microsoft were able to provide some sort of check on the location of problematic resources.
I have a situation where I get an exception in a dynamic assembly, which in turn terminates my application. I assume this assembly is generated by some of the third party libraries we use, because we don't use Reflection.Emit or other codegen tools ourselves. However, as far as I can tell, there is no way for me to determine where it comes from?
This is the exception I get:
An unhandled exception of type 'System.ArgumentException' occurred in Unknown Module.
Additional information: An item with the same key has already been added.
Is there tooling, or some code I can write into my own application, to figure out what is going on?
Go to Debug -> Exceptions:
Exceptions dialog http://blogs.msdn.com/cfs-file.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-82-17-metablogapi/5824.image_5F00_thumb.png
then check the Thrown checkbox on the Common Language Runtime Exceptions line (or directly on the ArgumentException line). This will make the debugger kick in as soon as any exception is thrown, before the stack is unwinded. You'll be able to examine the call stack at this point.
Note that you may also have to disable the following option:
Tools -> Options -> Debugging -> General -> Enable Just My Code
And in the call stack window, enable Show External Code from the context menu:
call stack context menu http://blogs.msdn.com/cfs-file.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-82-17-metablogapi/5672.image_5F00_thumb_5F00_3.png
I've recently started using a private NuGet server to manage my organization's internal libraries. This means in order to step into our own code that is in a library, I need to disable "Enable Just My Code" in debugging options since we aren't referring to the projects directly any more. This is a pretty hefty MVC project that uses dynamic types and ExpandoObjects in addition to ViewBag. I get two RuntimeBinderExceptions for every single use of a dynamic type... which is a lot. This appears to be normal behavior from what I've read. Normal it may be, but useful it is not.
My first thought was to disable this particular exeption in the Debug-> Exceptions dialog. The exception is not to be found there. I can't figure out any way to be able to step outside the projects referenced directly, without also opening myself up to these exceptions. (And all manner of other low-level framework exceptions that I don't want to hear about, but this is the biggest offender by far).
What's the best way to deal with this?
Edit: This is the problem. How do I stop this with "Enable Just My Code" disabled?
You can add additional "exception" names (existing in your own code or other libraries)...so long as you know the exception's fully qualified type name.
Managing Exception with the Debugger
https://msdn.microsoft.com/en-us/library/x85tt0dd.aspx
In Visual Studio 2010
Via the Debug | Exceptions... dialog.
Use the Add button to add a new exception under the Common Language Runtime Exceptions group and call it Microsoft.CSharp.RuntimeBinder.RuntimeBinderException
then just make sure Thrown and User-Handled are NOT ticked - thus causing the first chance exception to be ignored, rather than being caught by the debugger.
In Visual Studio 2017
Via the Debug | Windows | Exception Settings... panel
Use + to add the new exception name
make sure it's unticked
I am using Windbg to load a crash dump from managed code (C#, a console application built for Any CPU), and crash dump is created on x64 platform. I am debugging on x64 platform.
I have using the following command to load private symbol of my application. Here are what the commands I am using in Windbg.
(set symbol path and copy FooService.pdb pdb file to local symbol path D:\Debug)
0:016> .reload /f
.*** WARNING: Unable to verify checksum for FooService.exe
DBGHELP: FooService.pdb- private symbols & lines
D:\Debug\FooService.pdb
0:016> lm
start end module name
00000000`00400000 00000000`0041c000 FooService C (private pdb symbols) D:\Debug\FooService.pdb
My confusion is, when using the following command, no line number information is showed in stack trace. Any ideas what is wrong? Do I need to set source path?
0:016> ~6 e!clrstack
EDIT 1: I met with some issues with using !pe and !U to find stack trace where the exception is thrown.
Here is my debug process. At first I use !pe to print stack trace for the exception object, when I use !U to diassemble the code. The issue I find is !U will diassemble all function code of FooService.ProcessOrders(), and I want to find the exact place where in function FooService.ProcessOrders the crash happens. I also find the diassembled annotated IL code only contains function calls I made (for non-function call C# code, for example a=a*2, only assembly language is shown), not exactly IL mapped to each line of C# code, (1) is that the correct expected behavior? (2) what is the solution or further suggestion to find the exact failed C# code from my analysis posted here?
!pe 0000064280155325
StackTrace (generated):
SP IP Function
000000001A56DA70 00000642B74E3B7A System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(System.Data.Common.DbAsyncResult, System.String, Boolean)
000000001A56DB10 00000642B74E3FCC System.Data.SqlClient.SqlCommand.ExecuteNonQuery()
000000001A56DB90 0000064280155325 FooService.ProcessOrders()
000000001A56F3E0 0000064280153A21 FooService.RountineJob()
!U 0000064280155325
thank in advance,
George
WinDbg/SOS doesn't map line numbers to the output of !clrstack. So as long as lm tells you that you have private pdb symbols for your own assemblies you setup is correct. Unfortuntately the current versions of WinDbg/SOS doesn't support source level debugging to the same extend as for native code.
EDIT: Regarding exceptions. When you do a !pe, it will tell you the call stack as well as offsets into the relevant methods. If you take the address from the IP column of the !pe output and do a !U on that, you will see the JITTED code for the relevant method. The IP column will be the last address of the code that generated the exception (so you have to do a little counting to find the correct instruction).
The disassembled output is annotated with .NET calls so it is no hard to map this against the IL or source code. That should help you identify exactly which throw statement you're looking for.
That being said, you will make debugging a lot easier if you split methods into a number of smaller methods. If you do that, the method name is usually enough to pinpoint the location of the exception. I realize that is not always an option, but it is worth considering.
I have a customer who is unable to run our program without it crashing and creating the error below in the Event log. As always it works just fine on our computers (tried 6+) but the customer is saying that as soon as the click on anything in the program they get the error below.
EventType clr20r3, P1 datamonitor.exe, P2 1.0.0.3, P3 49dbd380, P4 datamonitor, P5 1.0.0.3, P6 49dbd380, P7 e9, P8 e5, P9 system.exception, P10 NIL
Any suggestions on how to locate such a problem?
Thanks
I suspect some required dlls are missing on your client's machines. Either they are using a differnt .Net version or you built your project whilst referencing something you have installed that they do not. I would double check you have included all your dependencies and try and set up a machine to replicate the config of your client, i.e. same OS, same .Net version etc. That should help you diagnose the problem.
If you can't isolate the exception you are throwing, see if the customer will allow you to copy over the Runtime Debugger. It's small, lightweight and will enable you to catch the exception and find out where it is coming from.
You can add code to catch unhandled exceptions in your code by adding a method to the AppDomain.UnhandledExceptionEventHandler.
See this example:
http://shiman.wordpress.com/2008/11/18/c-net-exception-appdomainunhandledexception/
With this, you might be able to catch this exception, and log out more detail, so you have more to go on.
Do you have any kind of logging in the application? That would be where I'd start, catch the exception and log it.
Also, seems unusual to have System.Exception thrown anywhere, maybe search your codebase('cause as far as I can remember, anything in the framework should throw a more specific exception).
I just struggled through this kind of a scenerio and wrote a blog post talking about it. But basically in your case datamonitor.exe crashed because of a system.exception. If you take IL Dissassembler you can view which class and method it is thats failing. p7 in your above error (e9) is the function you need to look for. This can be found by searching the dll for 06000e9 with the IL Dissassembler.
http://corymathews.com/eventtype-clr20r3-p1-w3wp-exe-system-nullreferenceexception/