I had created a spec several days ago and needed to create a new one. Instead of creating a new step implementation I used the same one as the previous spec. And since a couple of the steps were similar to the first spec I copy pasted the steps and changed what I needed. Then made the changes in the spec file to match the implementation. After a clean and build I noticed the steps were red (needing to be implemented, so I clicked implement step, and selected the file, which crashed VS17. It restarted by itself and gave me an error which you see below. Deleting the step implementations it still crashes. Deleting the step and implementation and rewriting them both still causes the crash, but the implementation is still generated.
Windows 10 Pro
Visual Studio community 2017
System.ArgumentException: An item with the same key has already been added.at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)at System.Collections.Generic.Dictionary2.Insert(TKey key, TValue value, Boolean add)at Gauge.VisualStudio.Model.Project.GetGaugeImplementations(Project containingProject)at Gauge.VisualStudio.Model.Project.RefreshImplementations()at Gauge.VisualStudio.Model.Project.HasDuplicateImplementation(ITextSnapshotLine line)at Gauge.VisualStudio.Highlighting.UnimplementedStepTagger.<GetTags>d__4.MoveNext()at Microsoft.VisualStudio.Text.Tagging.Implementation.TagAggregator1.d__39.MoveNext() --- End of stack trace from previous location where exception was thrown --- at Microsoft.VisualStudio.Telemetry.WindowsErrorReporting.WatsonReport.GetClrWatsonExceptionInfo(Exception exceptionObject)
Related
My main program is an ASP.Net Core Web API that has a third party library in a hosted service. The third party library is initializing fine but then it throws some errors sometime throughout its lifecycle.
It supplies a way of hooking into the object via an event and will let me know what the error is so that I can handle it but it still throws in the third party library..
Since I am handling the event myself, I want to completely ignore these errors that are occurring in this library. Is there anyway that I can do that?
I have already tried to add a global exception handler and the strange thing is, this exception handler never gets hit. The only way I can get the exception is to set my exception settings to break when CLR exceptions happen like in the picture above
This does not crash my program. For some reason, the program just hangs. When I turn off CLR exceptions in the "Break when thrown" window, then the program runs just fine. It is almost like visual studio is doing something special to handle these types of exceptions that a console version cannot do
The only way that I can seem to get a console version of this running, is attach a visual studio debugger to the process and when the exception is hit, press the green play button "Continue" in visual studio. Otherwise the application just seems to hang on the exception being thrown by the third party library.
The application will run fine as long as visual studio is attached and the CLR break exceptions are not checked
Does anyone know how to make sure that these types of exceptions do not hang the program when released?
Additional Info:
The third party library is a .NET Framework 4 library
The Asp.Net project is targetting "net5.0-windows"
The 3rd party class is probably using multi-threading
if it helps, this is how I am creating the third party class
Handling NullReferenceException in release code（Official advice）
It's usually better to avoid a NullReferenceException than to handle it after it occurs. Handling an exception can make your code harder to maintain and understand, and can sometimes introduce other bugs. A NullReferenceException is often a non-recoverable error. In these cases, letting the exception stop the app might be the best alternative.
However, there are many situations where handling the error can be useful:
1.Your app can ignore objects that are null. For example, if your app retrieves and processes records in a database, you might be able to ignore some number of bad records that result in null objects. Recording the bad data in a log file or in the application UI might be all you have to do.
2.You can recover from the exception. For example, a call to a web service that returns a reference type might return null if the connection is lost or the connection times out. You can attempt to reestablish the connection and try the call again.
3.You can restore the state of your app to a valid state. For example, you might be performing a multi-step task that requires you to save information to a data store before you call a method that throws a NullReferenceException. If the uninitialized object would corrupt the data record, you can remove the previous data before you close the app.
4.You want to report the exception. For example, if the error was caused by a mistake from the user of your app, you can generate a message to help them supply the correct information. You can also log information about the error to help you fix the problem. Some frameworks, like ASP.NET, have a high-level exception handler that captures all errors to that the app never crashes; in that case, logging the exception might be the only way you can know that it occurs.
So after days of research I've finally found an event to hook into to give you error messages from ANY source no matter how many level deep you go in threads.
AppDomain.CurrentDomain.FirstChanceException += CurrentDomain_FirstChanceException;
Hooking into this event it will allow you to see errors from every library and every thread. Simply place the above into you program.cs (or whatever startup file you have) and magically you will be flooded with all of the unknown errors from all of the 3rd party libraries you thought were once flawless.
private static void CurrentDomain_FirstChanceException(object sender, System.Runtime.ExceptionServices.FirstChanceExceptionEventArgs e)
{
Console.WriteLine(e.Exception.Message, e.Exception.StackTrace);
}
I've done so with the following method and low and behold. The third party library was trying to reference another project in an unsafe way and throwing an error. Since I didn't need this other project reference the built exe did not have a reference to this assembly because I had no direct reference to it in the project (darn smarty pants who need to optimize everything). I was able to run correctly because in my visual studio solution, I had a reference to this other project. So the third party library would pick up on it as soon as visual studio connected with the debugger through some sort of dark magic.
Anyways, I made a throw away object that used the project that was required and the issue was solved.
I really hope that this helps someone else and saves them the days it took me to find this.
I have some very simple code that is throwing a RuntimeBinderException
var mockString = "{ Status: \"Aware\" }";
dynamic d = JsonConvert.DeserializeObject(mockString);
OutputString = d.Status;
I have read a lot of the similar questions like this one and the answer given is that it is a first chance exception and I should check "Just My Code' in Tools > Options > Debugging.
I have the code in two solutions. One works and one does not. Both have the "Just My Code" option checked. Both are using the same version of Newtonsoft.Json (8.0.3)
This is VS 2015, Xamarin Forms running on Android.
In my case I had the debugger break on first chance exceptions for RuntimeBinderException, but when running on Android it was shown as "unhandled" exception in the debugger.
That threw me off for a moment, but after I found out I could continue running without problems I realised it was actually a first chance exception. After turning break on first chance exception of for RuntimeBinderException (since I wasn't interested in those at the time) it worked as expected.
To turn break on first chance exceptions on/off check the menu: Debug -> Windows -> Exception settings
I wanted to try out IDEA because I kinda want to move away from Eclipse. However, everytime I try to build or run code from inside IDEA, it just crashes with no error message. The only information I get is from Windows itself:
Problemsignatur (Problem signature):
Problemereignisname (Problem event name): BEX
Anwendungsname (Application name): idea.exe
Anwendungsversion (Application version): 14.0.3.0
Anwendungszeitstempel (Application timestamp): 5437b4c8
Fehlermodulname (Error module name): SDHook32.dll
Fehlermodulversion (Error module version): 2.3.39.2
Fehlermodulzeitstempel (Error module timestamp): 535a5137
Ausnahmeoffset (Exception offset): 00025942
Ausnahmecode (Exception code): c0000417
Ausnahmedaten (Exception data): 00000000
Betriebsystemversion (Operating system version): 6.1.7601.2.1.0.256.48
Gebietsschema-ID (Area schema ID): 3079
Zusatzinformation 1 (Additional information 1): 6ec5
Zusatzinformation 2 (Additional information 2): 6ec5ee19c106a54dd0feced4a6ea5c17
Zusatzinformation 3 (Additional information 3): 633b
Zusatzinformation 4 (Additional information 4): 633bad3421e95a8b92bd60a69d1ca25c
Sorry that it is in German, I tried to translate the keys into English but don't know if they actually match the English version of the error message. I'm running Windows 7 64-bit, error happens with both 32-bit and 64-bit version of IDEA. Used JDK is 1.8.0_20 (also 64-bit).
Can't seem to find anything about this on Google, maybe one of you knows how to fix this.
This is a windows issue. It's just that it is happening to you when using IntelliJ IDEA. The key in the error message is the Problem Event Name: BEX line. BEX refers to Buffer Overflow Exception. Take a read through the post Problem Event Name: BEX, error message on Microsoft Answers and the Data Execution Prevention TechNet article referenced in that answer. You can also Google windows bex crash or a similar term. Most information refers to the need to make a settings change to the "Data Execution Prevention" option. If you continue to have issues, you may want to post as a Windows-7 question on SuperUser.com
The crash happens in a DLL which is part of this application. You may want to uninstall the application if you don't need it.
When I enable Page Heap for my process under test, it triggers an Access Violation which indicates to me some type of heap corruption has occurred when SHGetFileInfo is called.
The top of the call stack shows msvcr90!wcspbrk and walking down it shows COM-related items in ole32 until shell32 is reached where we call SHGetFileInfo.
From what I've found online, a common problem for weirdness using shell32 is not calling CoInitialize/CoInitializeEx first, but at this point CoInitializeEx() has already been called, and calling it immediately prior to the below code simply returns S_FALSE.
The below code is in our DLL which is PInvoked from .NET (the code is used to retrieve the icon used for a particular file):
SHFILEINFOW shfi;
memset(&shfi,0,sizeof(shfi));
SHGetFileInfoW(A2W("C:\\logfile.txt"),
FILE_ATTRIBUTE_NORMAL,
&shfi,
sizeof(shfi),
SHGFI_USEFILEATTRIBUTES
| SHGFI_ICON
);
(where logfile.txt is random text file on my root drive)
I've hard-coded the first parameter to a file on my machine for simplicity.
I'm using a 64-bit Windows OS, but the code is run in a 32-bit context. I get the same result if I use the narrow version of SHGetFileInfo.
If I disable Page Heap for my process, there is no problem.
When I don't use the flag SHGFI_ICON, the issue doesn't occur.
EDIT: #HansPassant requested I add a reproduceable sample, here's a link to a Visual Studio 2010 Win32 Console Application demonstrating the issue: sample
I have a .Net Compact Framework 3.5 application that uses Nlog version 2.0 to log Info, Error and Fatal Exceptions. Most of the time the logging works as expected and logs fatal exceptions before crashing. But at times it is observed that application crashes without leaving any signs of an error/exception.
Let me elaborate the scenario:
The Application creates few threads, all the threads have try-catch block added at the beginning of their call stacks. And hence log fetal
exceptions before crashing.
The main thread have 'AppDomain.CurrentDomain.UnhandledException' to log any fetal exceptions on its call stack.
The application does load some third party managed dlls and performs some PInvokes on Wnce dlls.
But I believe even if some third party DLL crashes (or let’s say it creates a new thread which crashes), I should at least see some ThreadAbortExceptions in the log, logged by my application's thread before exiting.
The key configuration parameters of Nlog are:
a. FileTarget.AutoFlush = true
b. FileTarget.KeepFileOpen= false
c. FileTarget is not wrapped in any async wrapper or in any buffered
wrapper.
Please let me know if I'm missing anything.
Possible reasons for the crash include OutOfMemory exception or StackOverflowException. From the documentation for the latter:
Version Considerations
In prior versions of the .NET Framework, your application could catch a StackOverflowException object (for example, to recover from unbounded recursion). However, that practice is currently discouraged because significant additional code is required to reliably catch a stack overflow exception and continue program execution.
Starting with the .NET Framework version 2.0, a StackOverflowException object cannot be caught by a try-catch block and the corresponding process is terminated by default. Consequently, users are advised to write their code to detect and prevent a stack overflow. For example, if your application depends on recursion, use a counter or a state condition to terminate the recursive loop. Note that an application that hosts the common language runtime (CLR) can specify that the CLR unload the application domain where the stack overflow exception occurs and let the corresponding process continue. For more information, see ICLRPolicyManager Interface and Hosting Overview.