I am running a C# application, and during run-time I get the following error:
The CLR has been unable to transition from COM context 0x20e480 to COM context 0x20e5f0 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.
Can anyone please help me out with the problem here?
Thanks a lot.
The main thread of your program has been busy executing code for a minute. It is not taking care of its normal duties, pumping the message loop. That's illegal when you use COM servers in a worker thread: calls to their methods cannot be dispatched until your main thread goes idle again.
It should be readily visible, your UI should be dead as a door nail. Windows should have replaced your main window with a ghost that displays "Not Responding". Closing the window won't work, no click events have any effect.
Whatever your main thread is doing should be done by a worker thread instead. The BackgroundWorker class is good for that, you'll find many usage help in the MSDN Library article for it. Use Debug + Break All, Debug + Windows + Threads if you have no idea what the main thread is doing.
One more possible cause: be sure to install service pack 1 if you are using the RTM version of VS2005.
To find which operation is blocking the context switch and causing the contextSwitchDeadlock MDA to be displayed, you can use the following steps. Note that I will be referring to Visual Studio 2012.
Reproduce the error. This could involve some trial and error.
Click 'OK' rather than 'Continue' in the Managed Debugging assistant which is displayed.
Ensure that the Debug Location toolbar is active by right clicking on the toolbar docking region and selecting 'Debug Location'. You should see a drop down list labelled 'Thread' in the toolbar if it is active.
The selected item in the Thread drop down list should be a thread other than the main thread as it will be a background thread that is complaining that the main thread is hogging all of the attention. Select the main thread in the drop down list.
You should now see the code that is blocking the context switch in the code editor.
Assuming that you decide against moving the resource intensive operation off your main thread - take a look at some of the other answers and comments here before you do - you have the following options to disable the Managed Debugging Assistants.
Within the Visual Studio Debugger
You can disable an MDA directly in the MDA dialog that is
displayed when the error occurs by unchecking 'Break when this
exception type is thrown'.
With Exception Settings dialog using the instructions below from MSDN.
...on the Debug menu, click Exceptions. (If the Debug menu does not contain an Exceptions command, click Customize on the Tools menu to add it.) In the Exceptions dialog box, expand the Managed Debugging Assistants list, and then clear the Thrown check box for the individual MDA.
Outside the Visual Studio Debugger
Registry Key (Machine Wide, All MDAs affected)
Environment Variable (Machine Wide, MDAs can be specified)
Application Configuration Settings (Application scope, MDAs can be specified)
Note: One of the first two options must be set to 1 for the third to have any effect.
In my case, the problem was a call to ObjectContext.SaveChanges() in the Entity Framework within a console application. With the MTAThreadAttribute applied to the Main() method the ContextSwitchDeadlock exception was no longer raised. I am unfortunately unsure of the full affects of this change.
This message indicates that some code of yours is trying to switch threads, and the target thread is busy. For example, a background thread trying to dispatch a call to the UI thread to update the UI, while the UI is running a tight loop for a while.
To actually figure out what's going on you need to break into the debugger and look at all the threads and what they are doing.
In some cases :
Debug -> Exceptions -> Managed Debug Assistants
and unchecking the ContextSwitchDeadlock item.
Simply select Exceptions from the Debug menu in the visual studio 2005 window , the Edxception Dialog box wil popup , select the Managed Debugging Assistants Exception Node , then select ContextSwitchDeadlock and remove the select from Thrown column . this will stop the vs from throwing the ContextSwitchDeadlock exception.
Hope this helps..
I ran into this issue when I was trying to figure out why my OracleDataReader was throwing an exception. I thought it was because it was getting assigned null because the exception was related to a parameter that was `null. So I did:
while (dr.Read())
{
while (dr != null) // <-- added this line
{
...
Turned out the dr was NEVER null and so the loop just went on and on until this message arrived, and on and on some more because you can click "Continue" to keep it going until you run out of memory (don't do this - click "OK" instead). So moral of the story, look for memory leaks that are streaming data from the database into memory in loops to infinity. The error is actually trying to warn you of a bad scenario. Best to heed it.
This error came up for me numerous times, and I traced it down to an iteration in DataGridViewRow, in which I set the checkbox value to true. Since I was running in debug mode, I had the option to continue, so I was able to do just this.
I hope this helps someone.
Finally, I found a working solution for my vb.net Windows Application Form
Application.DoEvents()
Statement somewhere within the loop.
Reference: https://earlybites.wordpress.com/2012/04/10/resolution-context-switch-deadlock-was-detected/
Assuming you are using Visual Studio, you can click Ctrl+Alt+E in the current project and exceptions window will display with select
Managed Debugging Assistants you should uncheck the "ContextSwitchDeadlock" option. then build a current project.
Related
I have a form with a button which opens a new form to add a new record to a table.
In Access on my PC (full version), everything works.
When I try to run it on a server with Access Runtime, I get an error saying something like:
this application has stopped working due to a runtime-error. The
application will now be closed
(I have the Dutch version, so I hope this comes close to the English dialog box message).
I debugged the VBA, but that doesn't seem to be the problem.
It has worked before:
Private Sub Knop62_Click()
DoCmd.OpenForm "Machines Toevoegen", , , , acFormAdd, _
acDialog, OpenArgs:=Me.Installaties_Id
End Sub
Well any un-handled error in the runtime will spit out the error message, and then as you experienced exit the application.
there are a good number of ways to approach this:
Improve error handling - make sure you don't encounter any un-handled error. I find this can be a LOT of work.
Another way? Compile your application down to a accDE. When you use a accDE, not only does the runtime ignore errors, not only does it NOT shut down?
It also means that all of your local and global variables are NEVER re-set. so global vars, and even global reocrdsets or anything else will retain their values, and do so even with errors. As a result:
Your application runs like a un-stoppable fright train.
Your local and even global variables retain their values. This allows use of application wide settings and variables that never re-set. And no re-sets ever occur even for un-handled errors. They remain intact for the given session (since the time the application was launched).
So, I would try running your application as a accDE on that server. It will not only become vastly more reliable, but it will also not shutdown on un-expected errors and even better it will retain the value of variables even when having encountered errors.
So it looks like you have some un-handed error. You can go on a treasure hunt to find this error, or just try a accDE in the meantime, and perhaps in the new years you might eventually track down the error or issue. But until then, just compile your application as a accDE.
To compile:
First, from VBA editor (just hit ctrl-g). And from the menu bar choose debug->compile. You MUST ensure that no compile errors exist before the next step.
If above compiles, then from UI (main ribbon), go file->Save and publish
From that panel, choose Make ACCDE.
Access will compile your application into a "access executable". Now try running this application with a accDE file extension on the other computer.
Exactly what the title says. When I'm debugging my project and I enter the part where the application restarts (using Application.Restart()) Visual Studio opens break mode. Is there any way to prevent this from happening and restart the application?
It also sometimes comes up with System.ComponentModel.Win32Exception: 'The operation was canceled by the user', is there a better way to restart the application? I can't simply reset the variables as I disposed a few of them.
My problem is about report viewer, I didn't know what is the cause of this problem. And it is only occurring occasionally. The problem says something like
Local Report Processing
-----------------------------------
...The process access the file path path\expresion_host_5bc339f79dc24f2fb4b34667e9fadb13.dll
because it is being used by another process
(sorry for not providing complete details, or image, they just chat me this)
but it didn't run, after close the form, i dispose the reportviewer and form, and if re-open it and do it many times, this error will show. And i'm freaking here to solve this, i tried to google it first but none of them help me with this.
by the way, in my workspace, this error is not showing.
but in my boss, this error is showing, maybe because he is using Windows 8.
1.) Application Run As Administrator
2.) When you Close Application at that time use Application.exit at end of code
When a report ( printing ) function is run, a dll ( it is a working temp file generated by application to set a parameter etc.. ) is created in a temp folder for a millisecond and deleted.
At that time if the new antivirus program is catch the file, it also checks and release. and it is locked while it is being checked and your application dump ( the error message ) at that time.
So remove your anti virus you will see problem will be solved. Stopping anti virus may not enough. AV services continue to check every file and blockes.
Background
We have a .NET WinForms application written in C# that interfaces to a handheld store scanner via a console application. The console application is written in good ol' VB6-- no managed code there. The VB6 application consists of several COM objects.
The .NET WinForms application refreshes the data in the scanner by invoking the console application with the right parameters. When the console application starts, it pops up a modal form reminding the user to place the handheld device into its cradle.
Problem
A customer has a bizarre situation in which the call to start the console application appears to hang before it displays the reminder form. If the user presses any key-- even something innocent like Shift or Alt-- the application unfreezes, and the reminder form appears. While it is hung, the CPU usage of the console application is very high.
We have obtained a memory dump from the command line application using ProcDump. I have some experience debugging managed dump files, but this VB 6 dump is strange to me.
We captured several full memory dumps in a row. In some of them, there appears to be COM glue stacks. For example, several dump files show a call stack like this:
msvbm60!BASIC_DISPINTERFACE_GetTICount
msvbm60!_vbaStrToAnsi
msvbm60!IIDIVbaHost
msvbm60!rtcDoEvents
msvbm60!IIDIVbaHost
msvbm60!BASICCLASS_QueryInterface
[our code which I think is trying to create and invoke a COM object]
It doesn't help that the only symbols I have are from our code. The Microsoft symbol server does not have a PDB file for msvbm60.dll (or at least not from their version which is 6.0.98.2).
Questions
I am suspecting there may be some COM threading issue that is happening only on their system.
1) How can I determine the thread state of each thread in a dump file? If this were a managed dump file, I would look at !threads and then !threadstate to figure out the thread states. There is no managed code, so I can't use sos.dll. I didn't see any hints using ~ and !teb.
2) Is there a way to see what COM objects have been created in a dump file? Again, in a managed dump, I can do a !dumpheap to get a list of managed objects. Is there something similar I can find for COM objects?
3) Can I determine the threading model of COM objects in the dump file?
You can dump thread state by using command:
~*
this will not display 'background' as a state, you will only see running, frozen or suspended.
I'm not sure how you can get information from COM objects, I have never tried but will investigate and get back to you, regards to threading model it will be difficult to infer that without painful monitoring of application state after stepping through and even with that, when you step through all other threads will run unless you use .bpsync 1 which syncs all threads to the current one, but that could cause a hang (e.g. gui thread has now been told to freeze) so I think it will be difficult unless you have access to the source code.
I can only answer question 1. Use !runaway to find the thread or threads consuming the CPU. To get all thread stacks use ~*kb1000.
I have a Window Forms application (using clickonce installation, running on a terminal server) that occasionaly ends up with a thread that appears to be running in a tight loop. The user doesn't know this happens as the app continues to run as expected. Also I have determined that I can kill the problem thread without any apparent affect on the app.
I can use Process Explorer to find the instance of an app with the problem and can isolate the thread with the problem but haven't found any way to look into the thread to find anything that would help me determine what is causing the problem. Does anyone know of a way to some additional information about a thread, like maybe strings, that would help me zero in on the issue?
Thanks,
Dave
Haven't tried this myself but "Process Monitor" claims it "shows real-time file system, Registry and process/thread activity"
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
Hope this helps.
You should be able to attach Visual Studio to the running process to get more information. Provided the .pdb files are included with the application and you have source code for the avialable version you should be able to use the Threads window combined with pausing / stepping through to see just what the code is doing.