Develop Reference

Application hangs when calling external constructor -- troubleshooting steps?

This may be a long shot but I'm out of ideas.
I've got a VS C# solution with three projects in it. There's a class library project and then two application projects that depend on that class library. The class library in turn depends on a few other DLLs including the avalonedit dll from the sharpdevelop project.
One of the applications is building and running fine, including a use of my own control that wraps the avalonedit control. The other application is failing to run and it seems to be failing at the point when the avalonedit control is initialised via the XAML in my wrapping control.
The problem is that I don't see any errors in the debug output at all, all I see is the dll loaded message and then nothing. If I step into the constructor of my control the step never completes. The debugger says the app is running, but it is apparently spinning somewhere in the avalonedit dll when the underlying edit control is constructed by the XAML side.
I have to assume that there's some issue with difference in environment between the two projects but I'm kind of stumped as to how to proceed in tracking the problem down. Am I going to have to somehow get arrange matters so that I can put a break in the avalonedit source?
Edit: If I pause/break all it just drops back to the line calling my control constructor.

Sounds like a deadlock. Take a close look at all threads, their stack traces and synchronization primitives (locks, semaphores, etc.). Keep in mind: contended resources may not be explicit (for example, when you are inside static constructor waiting on something that tries to get access to a static field of the type being constructed you get a deadlock).
There are many ways to introduce a deadlock but no simple advice to handle it. You could also enable break on all exceptions in Visual Studio (Debug -> Exceptions... and tick CLR Exceptions).
If this does not help you could provide stack traces here and maybe somebody could spot the problem.

Debugging C# Threads

When I am working on multithreads how can I debug to know which thread causes an abnormal behavior?
Can I use permonitor for debugging, or are there any other tools or debugging facilities that are available?

Tips for Debugging Threads From MSDN
Neat New Multithreaded Debugging Features in VS 2008 by John Robbin

As an alternative to debugging, you could do thread-related testing. The book The Art of Unit Testing has a section on this in Appendix B. The author mentions three tools (two of which he has a personal interest in):
Typemock Racer
Microsoft CHESS
Osherove.ThreadTester

You can use visual studio to set up breakpoints on certain threads. See here and here for how to do it.

It depends what do you mean by "abnormal behavior"...
for most of the time, the visual studio debugger should be enough. the Threads and CallStack windows will give you a lot of information about what is going on.
for the heavy duty stuff you can use WinDbg+SOS. read about the !threads, !threadpool and !runaway commands.

If you have several threads of the same type* you could modify your code to only run one of each type of thread (or perhaps put it in the application's configuration file so you can change it quickly while debugging).
If the application still misbehaves then you know that it's an interaction between the different types of thread that's causing the problem. If it doesn't then it could be that there's some resource you've not thread locked properly (for example).
What I'm trying to say is simplify you application to the point where it's using the minimum number of threads to still be your original design.
* Not the best word to use, but for example if you spawn 10 threads to deal with file i/o only spawn 1.

How do you define abnormal behavior? Would that be an exception thrown? Not sure if this will help you but What I often do is name the thread object when I create it, then if I catch an exception or if certain criteria exists, I write to the event log. I include the time, the application name, the name of the thread and exception information. I don't just use it for debugging, I use it if a user complains about odd behavior or reports an error. Then I can go back and get information about it.

Not enough storage is available to process this command in VisualStudio 2008

When I try to compile an assembly in VS 2008, I got (occasionally, usually after 2-3 hours of work with the project) the following error
Metadata file '[name].dll' could not be opened --
'Not enough storage is available to process this command.
Usually to get rid of that I need to restart Visual Studio
The assembly I need to use in my project is BIG enough (> 70 Mb) and probably this is the reason of that bug, I've never seen some thing like this in my previous projects. Ok, if this is the reason my question is why this happens and what I need to do to stop it.
I have enough of free memory on my drives and 2Gb RAM (only ~1.2 Gb are utilized when exception happens)
I googled for the answers to the questions like this.
Suggestions usually related to:
to the number of user handlers that is limited in WinXP...
to the physical limit of memory available per process
I don't think either could explain my case
For user handlers and other GUI resources - I don't think this could be a problem. The big 70Mb assembly is actually a GUI-less code that operates with sockets and implements parsers of a proprietary protocols. In my current project I have only 3 GUI forms, with total number of GUI controls < 100.
I suppose my case is closer to the fact that in Windows XP the process address space is limited with 2 GB memory (and, taking into account memory segmentation, it is possible that I don't have a free segment large enough to allocate a memory).
However, it is hard to believe that segmentation could be so big after just 2-3 hours of working with the project in Visual Studio. Task Manager shows that VS consumes about 400-500 Mb (OM + VM). During compilation, VS need to load only meta-data.
Well, there are a lot of classes and interfaces in that library, but still I would expect that 1-2 Mb is more then enough to allocate metadata that is used by compiler to find all public classes and interfaces (though it is only my suggestion, I don't know what exactly happens inside CLR when it loads assembly metadata).
In addition, I would say that entire assembly size is so big only because it is C++ CLI library that has other um-managed libraries statically linked into one DLL. I estimated (using Reflector) that .NET (managed) code is approx 5-10% of this assembly.
Any ideas how to define the real reason of that bug? Are there any restrictions or recommendations as to .NET assembly size? (Yes I know that it worth thinking of refactoring and splitting a big assembly into several smaller pieces, but it is a 3rd party component, and I can't rebuilt it)

The error is misleading. It really should say "A large enough contiguous space in virtual memory could not be found to perform the operation". Over time allocations and deallocations of virtual memory space leads to it becoming fragmented. This can lead to situations where a large allocation cannot be filled despite there being a plenty total space available.
I think this what your "segmentation" is refering to. Without knowing all the details of everything else that needs to load and other activity which occupies the 2-3 hour period its difficult to say whether this really is the cause. However I would not put it into the category of unlikely, in fact it is the most likely cause.

In my case the following fix helped:
http://confluence.jetbrains.net/display/ReSharper/OutOfMemoryException+Fix

As Anthony pointed out, the error message is a bit misleading. The issue is less about how big your assembly is and more about how much contiguous memory is available.
The problem is likely not really the size of your assembly. It's much more likely that something inside of Visual Studio is fragmenting memory to the point that a build cannot complete. The usual suspects for this type of problem are
Too many projects in the solution.
Third party add-ins
If you have more than say 10 projects in the solution. Try breaking up the solution and see if that helps.
If you have any 3rd party addins, try disabling them one at a time and seeing if the problem goes away.

I am getting this error on one of my machines and surprisingly, this problem is not seen on other dev machines. May be something wrong with VS installation.
But I found an easier solution.
If I delete the .suo file of teh solution and re-open the solution again, it will start working smoothly.
Hope this will be useful for somebody in distress..

If you are just interested to make it work then restart your computer and it will work like a charm. I Had same kind of error in my application and then after reading all of the answer here at stackoverflow, I decided to first restart my computer before doing any other modifications. And it saved me a lot of time.

Another cause for this problem can be using too many typed datasets via the designer. or other types that can be instaniated via a designer like lots of databound controls on lots of forms.
I imagine your the sort of hardcore programmer though who wouldn't drag n' drop a DS! :D
in relation to your problem, Bogdan, have you tried to reproduce the problem w/o your c++ component loaded? If you can't then maybe its this. How are you loading the component? have you tried other techniques like late binding, etc? any difference?
Additional:
Yes you are right, the other culprits are lots of controls on the form. I once saw this same issue with a dev that had imported a very VB6 app over to .net. he had literally 100's of forms. He would get periodic crashing of the IDE after a couple of hours. I'm pretty sure it was thread exhaustion. It might be worth setting up a vanilla box w/ no addins loaded just to rule addins out, but my guess is you are just hitting the wall in terms of a combined limiation of VS and your box specs. Try running Windows Vista 64bit and install some extra RAM modules.

If memory usage and VM size is small for devenv.
Explicitly kill "ALL" instances of devenv.exe running.
I had 3 devenv.exe running where as I had two instances of Visual studion opened in front.
That was solution in my case.

I know it has been a long time since this was commented on but I ran into this exact issue today with a telerik dll in VS2010. I had never seen this issue before until today when I was making some setting changes in IE.
There is a setting in Tools/Folder Option/View in the Files and Folders section called "Launch folder windows in a separate process".
I am not sure the amount of memory used for each window when using this setting but until today I have never had this checked. After checking this option for misc reasons I started getting the "not enough storage is available to process this command". The telerik dll is an 18mb dll that we are using located in our library folder as a reference in our project.
Unchecking this resolved the problem.
Just passing along as another possible solution

I also faced the same problem.
Make sure that the windows os is with 64bit.
I switched to windows 64bit from windows 32bit. I problem got solved.

I had this same issue and in my case, the exception name was very misleading. The actual problem was that the DLL couldn't be loaded at all due to invalid path. The exception i was getting said "
I used DllImport attribute in C#, ASP.NET application with declaration like below and it was causing the exception:
[DllImport(#"Calculation/lib/supplier/SupplierModule.dll", CallingConvention = CallingConvention.StdCall, CharSet = CharSet.Ansi, EntryPoint = "FunctionName")]
Below is working code snippet:
[DllImport(#"Calculation\lib\supplier\SupplierModule.dll", CallingConvention = CallingConvention.StdCall, CharSet = CharSet.Ansi, EntryPoint = "FunctionName")]
The actual problem was using forward slashes in path, instead of back slashes. This cost me way too much to figure out, hope this will help others.

C# app runs with debugging, but not without [closed]

Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 7 years ago.
Improve this question
I'm running a (mostly) single threaded program (there's a main thread that does everything, the others only read stuff). I can get the application to run fine in VS2008 after a minor change (I changed the text of a form, and tab order of another form), but I can no longer get it to work outside of the debugger. Does anyone know what would cause this?
Clarification: Release mode, launched with debugger (F5) works. Debug mode, lanuched with debugger (F5) works. Debug executable, or release executable launched outside of VS or with Ctrl+F5 fail.
It uses Microsoft's Virtual Earth 3D, and it seems to crash just when the 'ring of hope' (loading ring) is about to complete.
Event log says: ".NET Runtime version 2.0.50727.3053 - Fatal Execution Engine Error (000006427F44AA6E) (80131506)"
Culprit: this line:
this.loader = PlugInLoader.CreateLoader(this.globeControl.Host);
Causes it to fail. However, the form that was working uses the exact same line without an issue. This line is nesseccary for the program to function. I have no idea what it's doing.
Another Lead the error seems to be inside the .NET framework. Application worked on another machine, attempting reinstall. Update: didn't make a difference, although when I repaired VS it kept telling me Visual Studio was crashing even though I wasn't running it.
Error
When I launch the program after a couple minutes I get:
Application has generated an exception that could not be handled.
Proccess ID=0x9CC (2508), Thread ID =0xF0C(3852).
Click OK to terminate the application.
Click CANCEL to debug the application.
The disassembly is bizarre:
0000000077EF2A90 int 3
0000000077EF2A91 int 3
0000000077EF2A92 int 3
0000000077EF2A93 int 3
0000000077EF2A94 int 3
0000000077EF2A95 int 3
0000000077EF2A96 xchg ax,ax
0000000077EF2A9A xchg ax,ax
0000000077EF2A9E xchg ax,ax
0000000077EF2AA0 int 3 <-- Crashes here
0000000077EF2AA1 ret
It repeats that same code block several times (minus on ax exchanging with itself)
Besides my computer, it has worked on every machine I've tested it on, except for a VM on my machine which won't install the .NET framework because setup downloads 0 bytes out of 0 bytes for the framework)...lovely windows.

I've had similar issues where timing conflicts were causing the failure, and my debugging (breakpoints and stepping through the code) forced the code to run in the correct order.

Try take off optimizations from the Release build (in the project settings) and see if that helps.

I fixed it, the .NET 2.0 Framework was corrupt and when I reinstalled it, everything magically started working again.

I cannot tell you what exactly the problem is, but here's what you could do to get a clue what's really happening. I assume you're using VS2008 or 2005.
Switch to release mode
Go to Debug\Exceptions, and mark all "Thrown" exceptions, like illustrated here: http://vvcap.net/db/JbWS_tzy2IpBoI7R7amm.htp
Run executable in debugger, ignore the warnings from VS that there's no debug info
It does seem that there's a win32 exception thrown some time during execution, but this way or another, you will get one or more messages from debugger explaining what kind of exception happened and where. In most cases those messages make it pretty clear what exactly went wrong
EDIT: One thing I forgot to mention is that unmanaged debugging must also be turned on, such like here (when you start program directly from IDE) or here (when you attach to running process)

Here is a support article with that error. Does that apply?
Perhaps the debugger is eating an excaption the VE3D API is throwing. In VS, do a ctrl+alt+e and change it to break whenever any exception is thrown. This can be tedius b/c it will break on all your try catch blocks, but it might give you some information.
Here is some info. about that PlugInLoader. It seems to imply it must be called from the FirstFrameRendered eventhandler. Perhaps one of your forms is doing that and one not?

Search for #if(DEBUG) directives?
Search for Debug.Assert(?
Have you googled the error? I found this thread (admittedly not horribly helpful)

I once had a similar problem with exactly the same behaviour using a plug-in-system. When loading a plug-in from a MarshalByRef-object (see example code below), it seems as if .NET creates a new AppDomain or Context for the loaded assembly. (Can anyone confirm this? I've not found any source regarding this.)
public class ProxyAssemblyLoader : MarshalByRefObject {
public Assembly GetAssembly(string path) {
return Assembly.LoadFrom(path);
}
}
Furthermore in my case the plug-in loads a different version of the mscorlib. (My app is CLR2 and the loaded is CLR4) Afterwards I used the plug-in by reflection and tried to access a value of the new mscorlib, which was loaded from the other application domain. Usually both should be usable because the mscorlib is a commonly used assembly and only loaded once (see Global Assembly Cache). But it seems as if this is not the case. But in general Microsoft advises to avoid that.
I've not exactly figured out what the problem was, but I figured out the call that causes the application to crash without any hint. Why without any hint? It crashed without any hint, because the thrown exception was only available in "the other" appdomain and not available for the main/default app domain.
The taken action was just implicit copying the value of another appdomains assembly to a local untyped value (object) in the default appdomain. This was enough to get a type identity mismatch error due different versions of the assembly. It seems as if Visual Studio could handle it, but if the application runs standalone it crashes.
This may also explains why you needed to reinstall your .NET. Maybe your installed .NET-Framework was a beta or something like that, which contained a minor difference.
In conclusion some general solutions for the problem could be:
Avoid using different versions of assemblies with different versions of the same type.
In other cases may try to load both assemblies inside the same appdomain. (As far as possible regarding the probing context.)
A solution for cross appdomain communication could be serialization of the values.
(Make sure that the correct .NET-Framework Non-Beta Version is installed.)

we found and fixed this issue with MSFT, we faced this problem with VSTO development.
Apply the following patch from MSFT.
http://support.microsoft.com/kb/975954
http://support.microsoft.com/kb/974372

One thing left I think is to use WinDbg to try and debug it. Here are some links on how to use it:
http://www.codeproject.com/KB/debug/windbg_part1.aspx
http://blogs.msdn.com/johan/archive/2007/11/13/getting-started-with-windbg-part-i.aspx
http://blogs.msdn.com/tess/ (good blog about debugging in general in windbg)
Thinking about it, it could also be some service or something that's clashing. Try stopping all unneeded services and closing unneeded programs (including startup ones) and see what happens then.

I had the exact same issue with one of my console applications. I determined that it was my antivirus (Avast) that was causing the issue.
Add the BIN folder to the exclusion list and disable "DeepScreen".
Then rebuild the project and try again!

How to debug a deadlock?

Other than that I don't know if I can reproduce it now that it's happened (I've been using this particular application for a week or two now without issue), assuming that I'm running my application in the VS debugger, how should I go about debugging a deadlock after it's happened? I thought I might be able to get at call stacks if I paused the program and hence see where the different threads were when it happened, but clicking pause just threw Visual Studio into a deadlock too till I killed my application.
Is there some way other than browsing through my source tree to find potential problems? Is there a way to get at the call stacks once the problem has occured to see where the problem is? Any other tools/tips/tricks that might help?

What you did was the correct way. If Visual Studio also deadlocks, that happens now and then. It's just bad luck, unless there's some other issue.
You don't have to run the application in the debugger in order to debug it. Run the application normally, and if the deadlock happens, you can attach VS later. Ctrl+Alt+P, select the process, choose debugger type and click attach. Using a different set of debugger types might reduce the risk of VS crashing (especially if you don't debug native code)
A deadlock involves 2 or more threads. You probably know the first one (probably your UI thread) since you noticed the deadlock in your application. Now you only need to find the other one. With knowledge of the architecture, it should be easy to find (e.g. what other threads use the same locks, interact with the UI etc)
If VS doesn't work at all, you can always use windbg. Download here: http://www.microsoft.com/whdc/devtools/debugging/default.mspx

I'd try different approaches in the following order:
First, inspect the code to look for thread-safety violations, making sure that your critical regions don't call other functions that will in turn try to lock a critical region.
Use whatever tool you can get your hands on to visualize thread activity, I use an in-house perl script that parses an OS log we made and graphs all the context switches and shows when a thread gets pre-empted.
If you can't find a good tool, do some logging to see the last threads that were running before the deadlock occurred. This will give you a clue as to where the issue might be caused, it helps if the locking mechanisms have unique names, like if an object has it's own thread, create a dedicated semaphore or mutex just to manage that thread.
I hope this helps. Good luck!

You can use different programs like Intel(R) Parallel Inspector:
http://software.intel.com/en-us/intel-parallel-inspector/
Such programs can show you places in your code with potential deadlocks. However you should pay for it, or use it only evaluation period. Don't know if there is any free tools like this.

Just like anywhere, there're no "Silver bullet" tools to catch all the deadlocks. It is all about the sequence in which different threads aquire resources so your job is to find out where the order was violated. Usually Visual Studio or other debugger will provide stack traces and you will be able to find out where the discrepancy is. DevPartner Studio does provide deadlock analysis but last time I've checked there were too many false positives. Some static analysis tools will find some potential deadlocks too.
Other than that it helps to get the architecture straight to enforce resource aquisition order. For example, layering helps to make sure upper level locks are taken before lower ones but beware of callbacks.