I have went through different questions and didn't really find anything that suited my problem, but I also didn't exactly know what to look up to get any results either, so I may have missed some entries. If anyone could link to something that might be of assistance, I would greatly appreciate it.
I'll start off by posting a code example that I'm using (Is not the exact code, as I cannot release this) that I think is causing the application to crash.
using (var editForm = new frmEditableText("Alarm Note", "Title"))
{
var result = editForm.ShowDialog(this);
if (result == DialogResult.OK)
{
string temp = editForm.ReturnValue;
string xPath = String.Format("AlarmsDb/Alarm[Id = '{0}']/Notes", alarmID);
if (!Tools.OverWriteXMLSingleNote(alarm_xml_path, xPath, temp))
logErr("Error overwiting XML alarm: {0}", xPath);
AlarmDb.SetNote(alarmID, temp);
}
}
Tools is a private codebase that houses miscellaneous universal tools that get ported from project to project.
I'm not exactly sure what is going on. I know this code works as it is working on all other code lines I have used it in.
The only thing that is different is the PC itself.
The way it's setup is in a datagridview, on cell click it pops up a form for you to put your notes for that specific row and save them.
Once the form pops up, I close it and immediately the app crashes and won't recover, but there is no exception being reported either.
This only happens when not running through visual studio (matters not if it's a release or debug build, only if it is or isn't running in visual studio).
I'm sure I may have missed some details, please let me know if there is any other information you need from me, but this about sums up my issue.
EDIT:
With some further debugging, I've added multiple log statements in all places possible that would have to do with the form closing, opening, doing it's intended purpose.
What I've found is the FormClosing event makes it all the way through.
ShowDialog(this) is expected to return a DialogResult enum value, but hangs at the point of which it is actually attempting to return this value causing the application to freeze up.
I've also found that setting thread priority to AboveNormal for the thread which ends up calling the form gets rid of the issue. However I do not think that is a good enough solution.
It appears there was an oversight on my end, although I'm still not certain if this is the correct way to resolve my issue.
I don't have very much knowledge on the whole ApartmentState being MTA or STA, or how to identify when which should be used.
What did solve my issue though was going through all the threads that are spun off my main thread and setting their ApartmentState to STA, which I thought was already done from a previous codeline to resolve another issue I was having (such is the problem with collaboration).
But yes, I went through the entirety of my solution and found all instances of new threads being created and explicitly setting their ApartmentState to STA has resolved the crashing issue.
If anyone can provide some good material defining the differences and when to use either, or how to identify when one should be used over the other, it would be greatly appreciated.
did you try subscribing to the AppDomain.UnhandledException event? You can use this as a final catch all (no pun intended) and log to a file the exception see
https://msdn.microsoft.com/en-gb/library/system.appdomain.unhandledexception(v=vs.110).aspx
Alternatively/additionally - did you look in the event viewer?
Good luck
Related
Two strange exceptions happened in .NET built-in components.
It's the same IO exception: "The process cannot access the file '......' because it is being used by another process".
In "cursor" case it's about ".tmp" file and exception happens somewhere at the end of the sequence of calls, when WPF grid is remeasured:
System.Windows.Controls.Grid.MeasureCell
...
System.Windows.Controls.GridViewColumnHeader.GetCursor
...
System.Windows.Input.Cursor.LoadFromStream <-- here
In "settings" case it's about ".newcfg" file and happens exactly on "save" method call.
The question is: how is this possible? And how to handle/prevent it?
I guess default implementations close XMLWriters and do everything correctly.
We had a single user with the same problem as your "settings" case (it's about ".newcfg"). It turns out that when they switched off their Norton Antivirus, the problem went away!
Some research I did prior to that may be of use:
Check if you have more than one thread capable of calling Settings.Default.Save(). If multiple threads are competing, it might produce this error, although I understand .NET is supposed to make this thread-safe.
It might possibly be happening if you have multiple calls to Settings.Default.Save() in quick succession, within the same thread. This can happen if several classes (e.g. user/custom controls) each want to save some settings, but none should have to be aware of the others' need to do this, and closing down the parent form causes each control to call the Save().
Check the user has appropriate write permissions in the target folder AND in the folder where the .exe is located. My colleague has seen a bizarre connection between the two!
Find all instances in your code where you call Settings.Default.Save(), and set a break point on all of them. When you run the program, you might notice some suspicious behaviour or pattern in the way they get called.
Hope this helps!
I am getting this error on code that used to work. I have not changed the code.
Here is the full error:
The CLR has been unable to transition from COM context 0x3322d98 to COM context 0x3322f08 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.
And here is the code that caused it:
var openFileDialog1 = new System.Windows.Forms.OpenFileDialog();
openFileDialog1.DefaultExt = "mdb";
openFileDialog1.Filter = "Management Database (manage.mdb)|manage.mdb";
//Stalls indefinitely on the following line, then gives the CLR error
//one minute later. The dialog never opens.
if(openFileDialog1.ShowDialog() == DialogResult.OK)
{
....
}
Yes, I am sure the dialog is not open in the background, and no, I don't have any explicit COM code or unmanaged marshalling or multithreading.
I have no idea why the OpenFileDialog won't open - any ideas?
One fix for the problem is to go to the Debug -> Exceptions -> Managed Debug Assistants menu in Visual Studio and uncheck the ContextSwitchDeadlock
From http://blog.wpfwonderland.com/2007/08/16/clr-has-been-unable-to-transition-from-com-context-for-60-seconds/
Update: Please, don't downvote, if you fairly think, that workaround is awful idea. A number of people tried a number of solutions listed as answers here, but my workaround was the only thing helped them. That's why the answer still has the positive score.
Figured it out - it automatically brings you to the last location you looked in every time the dialog opens. If that location is a network location that no longer exists (ex. the other computer is off), it will just hang forever.
My workaround looks like this:
string initialDirectory = ...; //Figure out an initial directory from somewhere
openFileDialog1.InitialDirectory = !Directory.Exists(initialDirectory)
? Path.GetPathRoot(Environment.SystemDirectory)
: initialDirectory;
So, it's complaining about a COM context even though you're not explicitly using COM because opening a native shell dialog underneath all that lovely c# code, and the shell does use COM.
What this message is telling you is that whatever it's trying to do, it's doing it on the UI thread and not in a nice way, and that seems to be taking a long time. Obviously whatever is wrong isn't your fault per-se, so you can ignore most of the advice it's giving you.
Things to try:
First I would try, as AaronLS suggest, simplifying your openFileDialog as much as possible. Try not setting anything; just create a new guy and call ShowDialog(). If that solves the problem, then you've just given it malformed parameters, and we can go talk about the implications of that. However if it does not work, that means that something is going wrong in shell land.
One possible reason this might happen is because you have a shell extension installed that is doing something bad. The best thing for you to do is break-in (ctrl+break in Visual Studio I think, or debug->break all on the menu bar) and get the complete stack for us. We should be able to identify the culprit by seeing who is on the stack when the dialog appears.
I got this problem while working with a large database and it made the UI freeze for a long period. So I put the codes in a BackgroundWorker and now the problem is gone. thanks to #i_am_jorf
What this message is telling you is that whatever it's trying to do,
it's doing it on the UI thread and not in a nice way, and that seems
to be taking a long time.
private void btnConvert_Click(object sender, EventArgs e)
{
Cursor = Cursors.WaitCursor;
bgwConvert.RunWorkerAsync();
}
private void bgwConvert_DoWork(object sender, DoWorkEventArgs e)
{
//My taking-lots-of-time codes
}
private void bgwConvert_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)
{
Cursor = Cursors.Default;
MessageBox.Show("Done");
}
I also had this problem, and I solved it by changing my .Net framework to the latest one (.Net framework 4.5 in my case; from project properties Window-> Debug-> .Net Framework), and changing the CPU type from x86 to Any CPU (in project properties Window-> Build-> Platform Target).
I just had the same problems moments ago, the solution in my case was simple:
Clean the solution and rebuild it!
I am using Visual Studio 2015.
Hope this one helps.
I have an application that is exhibiting strange behavior that I'm having trouble figuring out. It works fine on my machine and many user machines. However on some machines, seemingly at random, it just hangs. I was able to get on a support online meeting with a user and run a trace on their system while it was stalled. Here is a trace screen shot:
It appears that for 29.6 out of 30 seconds some threads were waiting on each other to complete, and were called almost 6,000 times. I've been trying to google this and have looked plenty here as well and from what I gather this suggests a thread deadlock condition. The problem is that this application only uses background threads in a few locations and this constructor shouldn't be one of them as far as I'm aware. Here is the code for the constrcutor:
InitializeComponent();
if (KMApplication.Settings != null)
{
_useWin10 = KMApplication.Settings.ForceSpellingMode == SpellChecker.SpellingModes.Windows10
|| (KMApplication.Settings.ForceSpellingMode == SpellChecker.SpellingModes.Automatic && Utility.IsWindows10());
}
The XAML for this control is pretty lengthy but I can copy it if necessary...
So my question is if anyone can tell from that what is going on, or if not what is the best way to go about looking for the issue here?
Ok so after a ridiculous amount of debugging and testing I figured out that this is not related to threading at all. It actually was related to spell checking of all things. It ended up being the issue shown in this question. If you look at the answer by am7zd they describe exactly what the issue ended up being. Not sure why it shows up this way in the trace but it's misleading, it's actually registering a bunch of dictionaries in all the text boxes and taking forever to create them. In the case of this user there were like 1800 non-existent files in that setting and once I cleared them up everything went back to normal speed.
Hopefully that helps someone running into similar issues...
whenever i try to run program for example,
if i have to run "frmphonebook" so in
Application.Run(new frmphonebook());
I typed but when i run it it run another form, and it happens to each and every form and it is displaying output as
The thread 'vshost.RunParkingWindow' (0x63c) has exited with code 0 (0x0).
The thread '<No Name>' (0xb24) has exited with code 0 (0x0).
how to solve this ?
You can give your threads a name it would also help you in your debugging...
But in many apps threads are created implicitly and you have no control over the name.
So that is not an error message. Code 0 means everything went according to plan. Any non-zero code usually indicates an error.
edit: You can also disable the display of these messages, when debugging, do right click on output, and choose what do you want see.
If a thread has exited with code 0 it ran successfully. On Codeproject is a Beginners-Guide-to-Threading
This article on threading might also be helpfull. This question on so could also be of use. A list of System Error Codes
One of the things you will learn about using the Debugger is that you will see what we might call "the soft white underbelly" (an allusion to alligators' anatomy) of the system: all kinds of DLLs being loaded and unloaded, the somewhat complex arrangement of "helper" threads being started and stopped... etc.
It can be distracting to a less experienced user, to see all of these messages. However, over time, you will come to understand that the Debugger is simply being truthful and verbose. The details it is displaying for you might not really be relevant to your debugging process, but it cannot "know" that; it is only displaying factual information, and you have to sort out what is relevant and what is not.
As for Windows Forms applications, I have myself noticed that there seem to be several "helper" threads, typically with no name, or (as is frequently seen by me when debugging), they are named things like "vshost.RunParkingWindow". Typically, you have to trust that the system is creating threads on your behalf, in addition to any threads you might create yourself. As others have suggested, give your own threads meaningful names so you can tell them apart from the system's threads.
You can get further insight into the multithreaded structure of your Windows Forms app by putting a breakpoint somewhere in your UI update code, and when it hits, use Debug/Windows/Threads to bring up a view of all the threads running in your process space. You'll be quite surprised, I think, by how many there are! Try creating and .Show()-ing several forms in your app, one by one. I think you'll see that each .Show() operation creates a new window, and with it, several supporting threads for that window.
You may also see messages in the debug window such as the following: "A first chance exception of type 'System.ObjectDisposedException' occurred in System.Windows.Forms.dll". Many times there are system exception handlers that perform a reasonable default action on your behalf. This message appearing without a break in the debugger indicates that some default handler took care of this exception for you.
The system support for something like a Windows forms application is somewhat complicated, to make YOUR implementation easier and simpler. When you run the debugger, you get to see some of these details. Over time, you will learn what is "usual" and what is indicative of a problem.
Check to see if there are some files in your web app that have been rendered inaccessible. For my case my chart control created a text file which was read only and it threw an exception. Deleted the file and the folders and voila
i found your solution i think....i the visual studio go to project >properties >linker >system look for the Subsystem line and click the down arrow and change to Console(....words....).
it worked for me !! ENJOY"
I am getting this error on code that used to work. I have not changed the code.
Here is the full error:
The CLR has been unable to transition from COM context 0x3322d98 to COM context 0x3322f08 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.
And here is the code that caused it:
var openFileDialog1 = new System.Windows.Forms.OpenFileDialog();
openFileDialog1.DefaultExt = "mdb";
openFileDialog1.Filter = "Management Database (manage.mdb)|manage.mdb";
//Stalls indefinitely on the following line, then gives the CLR error
//one minute later. The dialog never opens.
if(openFileDialog1.ShowDialog() == DialogResult.OK)
{
....
}
Yes, I am sure the dialog is not open in the background, and no, I don't have any explicit COM code or unmanaged marshalling or multithreading.
I have no idea why the OpenFileDialog won't open - any ideas?
One fix for the problem is to go to the Debug -> Exceptions -> Managed Debug Assistants menu in Visual Studio and uncheck the ContextSwitchDeadlock
From http://blog.wpfwonderland.com/2007/08/16/clr-has-been-unable-to-transition-from-com-context-for-60-seconds/
Update: Please, don't downvote, if you fairly think, that workaround is awful idea. A number of people tried a number of solutions listed as answers here, but my workaround was the only thing helped them. That's why the answer still has the positive score.
Figured it out - it automatically brings you to the last location you looked in every time the dialog opens. If that location is a network location that no longer exists (ex. the other computer is off), it will just hang forever.
My workaround looks like this:
string initialDirectory = ...; //Figure out an initial directory from somewhere
openFileDialog1.InitialDirectory = !Directory.Exists(initialDirectory)
? Path.GetPathRoot(Environment.SystemDirectory)
: initialDirectory;
So, it's complaining about a COM context even though you're not explicitly using COM because opening a native shell dialog underneath all that lovely c# code, and the shell does use COM.
What this message is telling you is that whatever it's trying to do, it's doing it on the UI thread and not in a nice way, and that seems to be taking a long time. Obviously whatever is wrong isn't your fault per-se, so you can ignore most of the advice it's giving you.
Things to try:
First I would try, as AaronLS suggest, simplifying your openFileDialog as much as possible. Try not setting anything; just create a new guy and call ShowDialog(). If that solves the problem, then you've just given it malformed parameters, and we can go talk about the implications of that. However if it does not work, that means that something is going wrong in shell land.
One possible reason this might happen is because you have a shell extension installed that is doing something bad. The best thing for you to do is break-in (ctrl+break in Visual Studio I think, or debug->break all on the menu bar) and get the complete stack for us. We should be able to identify the culprit by seeing who is on the stack when the dialog appears.
I got this problem while working with a large database and it made the UI freeze for a long period. So I put the codes in a BackgroundWorker and now the problem is gone. thanks to #i_am_jorf
What this message is telling you is that whatever it's trying to do,
it's doing it on the UI thread and not in a nice way, and that seems
to be taking a long time.
private void btnConvert_Click(object sender, EventArgs e)
{
Cursor = Cursors.WaitCursor;
bgwConvert.RunWorkerAsync();
}
private void bgwConvert_DoWork(object sender, DoWorkEventArgs e)
{
//My taking-lots-of-time codes
}
private void bgwConvert_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)
{
Cursor = Cursors.Default;
MessageBox.Show("Done");
}
I also had this problem, and I solved it by changing my .Net framework to the latest one (.Net framework 4.5 in my case; from project properties Window-> Debug-> .Net Framework), and changing the CPU type from x86 to Any CPU (in project properties Window-> Build-> Platform Target).
I just had the same problems moments ago, the solution in my case was simple:
Clean the solution and rebuild it!
I am using Visual Studio 2015.
Hope this one helps.