When there's an exception, it takes a few seconds for the exception assistant to pop up. Why?
It's probably unwinding the stack. If you don't need that, go to Tools->Options->Debugging->General "Unwind the call stack on unhandled exceptions".
Related
I am fairly new to Xcode and I have a question regarding how to trace back a bad access exception.
When I run my program in Xcode 6.4, it crashes and says there is a bad access somewhere. I can look into it and see all the assembly codes. However, when I try to use exception breakpoint to trace where the bad access actually comes from in the source code, nothing happens.
I have no idea what is going on and it would be appreciated if someone can help.
"Bad access" has nothing to do with exceptions. It's a signal, not an exception. Your program stops exactly at the point of the bad memory access. Follow the stack trace up to identify the code calling it. More importantly, use the static analyzer to show you problems, and turn on warnings to show you even more problems.
(The reason why you should set an exception breakpoint is that exceptions - not signals - end up in the debugger when it is found that nobody is catching the exception, at which point lots of evidence is destroyed. Exception breakpoint stops right when the exception is thrown, so you can follow the stack trace as well).
I'm working on an app in VS 2010 on wind2008. It's a .Net 3.5 app that use .Net 2.0 library.
I change all Frameworks to 3.5 .Net and uncheck "Enable the visual studio hosting process"
But When I debug my solution I got this error :
Problem signature:
Problem Event Name: APPCRASH
Application Name: AnalyseFarm.exe
Application Version: 1.0.0.0
Application Timestamp: 5326f157
Fault Module Name: KERNELBASE.dll
Fault Module Version: 6.1.7600.16385
Fault Module Timestamp: 4a5bdfe0
Exception Code: c000041d
Exception Offset: 000000000000aa7d
OS Version: 6.1.7600.2.0.0.274.10
Locale ID: 1036
Additional Information 1: 5ecb
Additional Information 2: 5ecbd308407466ba89616cb69c9e62d8
Additional Information 3: 9ac0
Additional Information 4: 9ac06af1219db569f0ee193c24745b31
any idea , beast regards
Exception Code: c000041d
This tells the tale, that's STATUS_FATAL_USER_CALLBACK_EXCEPTION, "An unhandled exception was encountered during a user callback". Your program threw an exception and it wasn't handled. Which normally automatically breaks into the debugger and displays the Exception Assistant.
However, the exception occurred at a very awkward time, just when the operating system was in a state where it cannot afford to go through the normal rigamarole that it goes through when a thread dies with an exception. This kind of mishap usually occurs when the callback was triggered by 32-bit code but the exception occurred in 64-bit code, there's no good mechanism to marshal 64-bit exceptions back into 32-bit code, the exception information cannot be properly interpreted by such code since it includes 64-bit pointer values. Or the other way around. Windows messages generated by the window manager tend to fall in this category. Beware that this is just a rough guess at the reason, you need to find the real one.
You do so by forcing the debugger to stop at the code where the exception is thrown, before the operating system is asked to deal with it. Use the Debug + Exceptions dialog, tick the Thrown checkboxes to force the debugger to stop at the throw location.
The app in question uses both native and managed code. The managed code provides just the UI layer while it links with a native dll which performs bulk of operations. The native dll links with some other static dlls. Now the issue is when I run the app it crashes non-deterministically. When I debug the app under managed code debugging, it shows that a particular function in the native code threw an "SEH" Exception. Stack trace just shows the current function. The error code that I get in the SEH Exception is EFAIL.
However the app runs fine every time under native debugger. The function which throws the SEH exception is single threaded. It doesn't uses any resources which may be accessed in any other thread. What could be the possible cause for this behavior? How should I go about detecting the origin of the exception in native code. Stepping-in under the debugger doesn't helps since the issue doesn't shows up when the app is running under the debugger.
I am using visual studio 2012.
Are you using DirectX?
SEH Exception occurres when DeviceContext is using from many threads
at the same time, because DeviceContext isn't thread safe.
I have been running an application developed under Windows 7 in Delphi XE on Windows 7 machine for about 3 weeks non-stop, but it stopped working after that and popped up a message box with "Control doesn't have parent window." After that nothing seem to work right in the software, unless it is shutdown and restarted.
I have an idea of what that error means, but I am trying to figure out. Why?
Any hints or suggestions will be greatly appreciated. Thank you.
Sign of a resource leak, window handles most likely. Diagnose with TaskMgr.exe, Processes tab. View + Select Columns and tick Handles, USER Objects and GDI Objects. Keep on eye on the values for your program while you are using it. A steady increase spells trouble, Windows stops giving more after 10,000.
If that doesn't help then improve your exception handling so you can get a better diagnostic, a stack trace is important to diagnose trouble like this.
You should install a copy of MadExcept, JclExcept, or other exception handling library that supports displaying/logging the call stack when an uncaught exception is raised (if you cannt reproduce the exception while running inside the IDE debugger, that is). Then you can figure out what your app was trying to do at the time of the exception, and hopefully narrow it down to the spot in your code that is accessing the specific UI control that is missing its Parent window.
I've integrated Flurry (http://www.flurry.com/) into my phone 7 app. The only code needed is this line in application launching
FlurryWP7SDK.Api.StartSession(ApiKeyValue);
However, as soon as that line is hit the application crashes with a KeyNotFoundException. The stack trace is included below. It appears to be querying isolated storage settings and failing when the key doesn't exist.
Does anyone have any experience with this error or even successfully integrating flurry into a Phone 7 app?
at System.ThrowHelper.ThrowKeyNotFoundException()
at System.Collections.Generic.Dictionary`2.get_Item(String key)
at System.IO.IsolatedStorage.IsolatedStorageSettings.get_Item(String key)
at A.ca98fb38190f0d5cad84c67a779d17229.c204dba68825403c905efd7bfd067b17b(String ce0360de492f1f363775feaf6d6a8ced5, Object c8d4be677f7ee63f6756e13f285072523)
at A.c3f1105d518a239d73e2236200494de25.set_cfca54db015a16ab23de44b4d5c65e9a3(String c8d4be677f7ee63f6756e13f285072523)
at FlurryWP7SDK.Api.StartSession(String apiKey)
at AppName.App.Application_Launching(Object sender, LaunchingEventArgs e)
at Microsoft.Phone.Shell.PhoneApplicationService.FireLaunching()
at Microsoft.Phone.Execution.NativeEmInterop.FireOnLaunching()
Edit
After discussions with Flurry support it appears that the KeyNotFoundException is caught by Flurry code. However if your debugger settings are to break when the exception is thrown you will break into the debugger regardless. Continuing execution will then work because the exception is caught and handled by Flurry.
I can't verify that this is the solution because I no longer have access to the dev environment that was indicating the error, but it appears to be a likely solution.
I work for Flurry. We have many successful deployments on the Windows 7 platform. You and Buju may be experiencing an emerging issue that has not come to our attention previously. Please email winmosupport#flurry.com as the diagnosis may involve discussing account specific details. Once we determine the underlying cause we can post back to this thread so the community has the benefit of our investigation. Thanks for working with Flurry.
Edit
I just wanted to follow up on Mac's comment as the KeyNotFoundException may manifest in two ways during debugging. As Mac noted we do caputure the KeyNotFoundException, however, the debugger sees the exception first before we can handle it within our library. The debugger's behavior is dictated by the setting in Debug > Exceptions.
If the checkboxes under Thrown are selected the program will be stopped and the stack trace above will be output. If the checkboxes under Thrown are not selected the output will generate an error like the following:
A first chance exception of type 'System.Collections.Generic.KeyNotFoundException' occurred in mscorlib.dll (this is the message Buju received)
The program will continue following this message as it just serves as a notice that an exception occurred somewhere within the program. More information on first chance exceptions can be found in the following articles:
What is a first chance exception - http://blogs.msdn.com/b/davidklinems/archive/2005/07/12/438061.aspx
How to handle (disable) first chance reporting - http://www.helixoft.com/blog/archives/24