I know little bit about the concept of application domain. We can delete the appdomain to unload the dll.
Is it possible to use appdomain for better exception handling? How it can be used?
As far as I know loading modules in child AppDomains will not offer better exception handling. In the MSDN page for AppDomain.UnhandledException Event it remarks that:
Starting with the .NET Framework version 2.0, this backstop for
unhandled exceptions in child threads was removed, because the
cumulative effect of such silent failures included performance
degradation, corrupted data, and lockups, all of which were difficult
to debug.
This means that an unhandled exception in a child thread even if the code is executed in a child AppDomain, will bring the whole process down.
Usually child AppDomains are used for the assembly unload feature that you mention, and for executing code in a sandbox (restricted security environment).
Related
I'm using a cortex m4 with freertos and i receive the following error
Err: -110595: Hardfault occurred!
I have no idea what to check.
The meaning is CRIT_ERR_HARD_FAULT but how do i trace it back?
It's always tricky and there is no common checklist what should be checked to give you 100% chance for quick success here.
Anyway checking several registers' values should give you enough information to proceed. To do it, you have to know what's the procedure of entering an exception - especially what's happening with core registers and the stack: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/Babefdjc.html
If you can use online debugging, put a breakpoint in hard fault handler and check the following:
stacked PC - as written in the article above, on exception entry ARM core automatically pushes registers r0,r1,r2,r3,sp,lr,pc and psr on stack. Look it up to check where the program was before execution
current LR - to verify if you came from Thread mode (normal program execution) or another interrupt compare current LR with the table in the article
ISR_NUMBER in IPSR being part of current PSR - to verify whether in fact hard fault exception occurred or your hard fault handler is used as a sink for all types of faults
CFSR and other fault related registers in SCB - it should give you more information what's exactly caused the problem. Since SCB is a peripheral block, it's not visible in most IDEs by default. Install peripheral plugin or simply access addresses via memory inspection window http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/Cihcfefj.html
If you're unable to do online debugging, you'll need a feature which will dump these registers somehow.
Good luck!
Are your HardFault handlers strongly defined? If you have the ability to connect a debugger and the fault is reproducible you can set a breakpoint in your fault handler and check the stack trace for possible areas of interest.
Alternatively, this guide provides a highly portable and useful method of diagnosing hard faults and gathering information post fault for the ARM processor.
I have a web application, using Spring-Boot. There is now a need for this application to use a custom dll (in house build dll file). There is nothing wrong with this dll, as we use it on our other applications, and have no problems with it.
To load the library in this new web application I'm writing, I have added the dll file to the procrun directory. This directory is on the library path, so that makes sense.
During startup I put in code to immediately load the dll, and also test some of its functionality. This works fine.
However, I have a timer, that schedules the execution of some functions, which may or may not include function calls to the dll.
At some point, about 10 minutes or so into execution, the service unexpected and seemingly without any valid reason, stops.
Although I try/catch exceptions at the appropriate logical places in code, there are no relevant log entries printed.
The Event Log shows something that reminds me of a null pointer exception:
Another bread crumb is that the event log will print something about the dll_unload. (see picture)
I need some help figuring out why the service is failing/stopping.
Kind Regards.
EDIT: After about three days of debugging and scratching my head, I came upon a forum thread that explained that this problem has something to do with the manner in which the system releases the memory during garbage collection. It seems that the dll in question was being unloaded by the garbage collector, even though it could still be called at some time later - which of course was the cause of the service falling over.
To solve the problem, I put in a timer that would call a method in the dll at three minute intervals (on my system this would not impact performance). I know this solution is a hack, but it works for me.
My program runs for about 10 hours during the night, sometimes I wake up to see that it has crashed (for whatever reason). It is usually a "Program Name" has stopped working, and the only button there is to close the program. I have tried watching and waiting for it to crash but the problem seems very hard to reproduce (and I can't watch it 24/7). I have used try and catch statements in my program in potentially problematic areas and told the program to dump to a text file if it catches an exception. But this isn't good enough it seems.
TLDR: Is it possible to tell my program to run a particular function when an exception has been detected in the program in general (without specifics) so that I can dump the stacktrace to a text file and investigate later?
Is it possible to tell my program to run a particular function when an exception has been detected...
Yes, but the specifics depend on the platform that you are using:
If you have a Console application, put a big Try ... Catch around Sub Main.
If you use WPF, add an event handler to AppDomain's or Dispatcher's UnhandledException event. Specifics can be found in the following question:
WPF global exception handler
In you use WinForms, you can also wrap Sub Main (which might be auto-generated) or attach to AppDomain.UnhandledException, see here for details:
WinForms Global Exception Handling?
For completeness, global exception handling in web applications is done in global.asax's Application_Error method:
How to catch unhandled exceptions in an asp.net application?
It's generally not a good idea to do this. You could, however, look at AppDomain.UnhandledException. This is pretty much restricted to one domain, and you'll also receive (potentially) notifications for all unhandled exceptions unrelated to your program.
This is usually used for class libraries, but I think with a bit of fiddle, you might get it to work.
I am using a TwainPro4.dll for scanning purposes in my VB.net application framework v3.5.
When i run my application i get the below exception, Please advise
LoaderLock was detected
Message: DLL 'C:\WINDOWS\assembly\GAC\PegasusImaging.WinForms.TwainPro4\4.0.22.0__80d669b8b606a2da\PegasusImaging.WinForms.TwainPro4.dll' is attempting managed execution inside OS Loader lock. Do not attempt to run managed code inside a DllMain or image initialization function since doing so can cause the application to hang.
I am assuming you mean when you debug your application you get this message. This message is important to understand. From MSDN:
"The loaderLock managed debugging assistant (MDA) detects attempts to execute managed code on a thread that holds the Microsoft Windows operating system loader lock. Any such execution is illegal because it can lead to deadlocks and to use of DLLs before they have been initialized by the operating system's loader. "
Now, to get the application to run in debug mode you can disabled the LoaderLock MDA in Debug Exceptions interface by Pressing (Ctrl+D, E) then open Managed Debugging Assistants tree and uncheck Loader Lock.
However! This is indicative of the DLL being initialized or written improperly. As such, again from MSDN,:
Typically, several threads inside the process will deadlock. One of those threads is likely to be a thread responsible for performing a garbage collection, so this deadlock can have a major impact on the entire process. Furthermore, it will prevent any additional operations that require the operating system's loader lock, like loading and unloading assemblies or DLLs and starting or stopping threads.
In some unusual cases, it is also possible for access violations or similar problems to be triggered in DLLs which are called before they have been initialized.
You may want to go back to the developer of the DLL and see what their approved resolution is.
Sources
http://msdn.microsoft.com/en-us/library/ms172219
http://msdn.microsoft.com/en-us/library/aa290048%28VS.71%29.aspx
While running unit tests, I'm getting the MDA shown below.
In the error message, what is the hexadecimal value refered to as a 'COM context'?
Can I determine this value for a given STA thread? If so, how?
Managed Debugging Assistant
'ContextSwitchDeadlock' has detected a
problem in 'C:\Program Files\Microsoft
Visual Studio
9.0\Common7\IDE\vstesthost.exe'. Additional Information: The CLR has
been unable to transition from COM
context 0x14cff0 to COM context
0x14d218 for 60 seconds. The thread
that owns the destination
context/apartment is most likely
either doing a non pumping wait or
processing a very long running
operation without pumping Windows
messages. This situation generally has
a negative performance impact and may
even lead to the application becoming
non responsive or memory usage
accumulating continually over time. To
avoid this problem, all single
threaded apartment (STA) threads
should use pumping wait primitives
(such as CoWaitForMultipleHandles) and
routinely pump messages during long
running operations.
From what I can see (looking at mscorwks disassembly) it is a IObjContext*, returned from CoGetContextToken().
Basically it looks like a call is queued up using IContextCallback::ContextCallback() from mscorwks!CtxEntry::EnterContextOle32BugAware(), which in turn calls mscorwks!CtxEntry::EnterContextCallback() once the object context (apartment) processes the message. They use a CLREvent to signal callback completion. For STA threads, not pumping messages would cause the event wait to timeout, which triggers the ContextSwitchDeadlock MDA.
Note: I'm not running this under a debugger so I can't confirm the behavior, but this is probably reasonably accurate.
I haven't seen that before, I suspect it's just an internal pointer. Neither thread IDs nor thread handles are usually that large.
There's been no way of getting the apartment type from the current thread, and I've never seen an apartment ID (other than a GUID representing the source/target apartment when marshalling) in native code.
The unit test is most likely running in MTA mode and you have code in it that displays a UI.
One COM context is visual studio, the other is the UI inside your unit test. You can either not display a UI or turn off the MDA.
It looks like the STA COM application does not spin the message loop. This would cause STA COM to just die. I got no idea what the COM context is but it strikes me that you should be able to reproduce your target app to just hang for long periods of time.
Sounds like there is a function that takes more than 60 seconds to run. Have you been able to isolate it?
EDIT This is the guy that wrote COM interop for .NET.
http://blogs.msdn.com/cbrumme/
Have a look at his blog or check out the boards that he frequents. He's written lots of stuff about why COM interop the way it is. It might help to ask this question on one of the Microsoft boards.