Need a VB error explaination (VB 2008 Express)

Topic

New Reply

A straightforward task takes about 10 minutes to run. To automate the task, I’ve brought in VB to “Shell” the task. After about a minute of running, VB gives up with an error screen titled “ContextSwitchingDeadlock was detected”. (It’s happened before with other tasks that run over a minute.) Could someone please tell me how to get around what ever these messages are complaining about? The error message:

The CLR has been unable to transition from COM context 0x5e3248 to COM context 0x5e30d8 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.

Thank you,
John Littell

Reply | Quote

Replies

If the task takes 10 minutes, I wouldn’t call it completely straightforward. What exactly are you doing in this task? Are you using BackgroundWorkers or threads?

Reply | Quote

Charlotte,
The “Shell” is to ZipBackup a popular file ziping program. It is part of my archiving system that organizes and stores daily backups, each 300GB in size, for the previous three weeks. It has always taken this long, but, as it was invoked manually, this was no problem. It is only now that I am making it part of a VB archiving system that it is causing a problem. It was also timing out when I was previously copying all the files directly from within VB code. Switching to ZipBackup was an attempt to do it all faster.

John

Reply | Quote

I used to get this executing long extracts from databases via ADO. Some of our tables are over 500 million rows. It’s caused by the ContextSwitchDeadlock Managed Debugging Assistant (MDA). It can be deactivated by going into Debug | Exceptions and then uncheck ContextSwitchDeadlock underneath Managed Debugging Assistants. If it isn’t shown under Debug then Right click on the toolbar area and select Customize. You’ll find it in the list of commands under Debug. Just drag it up to your Debug menu. It wasn’t in the menu with my install. It can also be deactivated via the app.config.

It’s occurring because you are essentially stalling the message loop by spending a lot of time running the ZipBackup program. The implications of disabling it are that you may lose a useful tool for discovering bugs before you release the application. MDAs are disabled in release builds anyway.

Hope this helps.
Kevin Bell

Reply | Quote

Kevin,
Thank you for jumping in. I followed your instructions to unckeck ContextSwitchDeadlock, and ZipBackup and my invoking code ran to completion. Just because I followed your instructions does not mean that I knew what I was doing. Therefore, two more questions please:
1. Is the unckecking of ContextSwitchDeadlock something that I should undo (recheck) later for other reasons?
2. Does your sentence “It can also be deactivated via the app. config.” mean that it can be unckecked and rechecked via VB code? If so, please show me how.

Thank you for your time and information,
John

Reply | Quote

I’m glad it helped. To answer your questions.

1. Disabling any debugging tool has consequences. In this case, because the message is pretty clear, i.e. your process is not pumping messages, and you know it’s because the shelled program is taking longer than the MDA likes it’s not a problem. I always switch any debugging tool back on when I am done with the current project. (There are a lot more Managed Debugging Assistants out there).
2. MDAs can be actrivated and deactivated via entries in the app.config but I’ve never done this. Please search for Diagnosing Errors with Managed Debugging Assistants in the MSDN or on the web. There is a lot more information there than is publishable here. As I dont know a lot about .config files I’m really not sure whether or not you can switch these MDAs on and off in code. I suppose it would depend on when the config file is read and if the settings inside it can be refreshed.

Regrads,
Kevin Bell

Reply | Quote

Kevin,
Thank you again for your help. Your last sencence “I suppose it would depend on when the config file is read and if the settings inside it can be refreshed.” makes sense. What I am going to pursue is another direction. As this is a function of Debug, would it not make sense that an .exe version of the program would work?

John

Reply | Quote

Remember that MDAs are disabled in Release builds and anyway, what would be the purpose of enabling a Debug feature when a user is running your program? If I were you, and of course I’m not, I would just let sleeping dogs lie. Use the MDA as a Debugging tool and forget about it when you release your program into the wild.

Regards,
Kevin Bell

Reply | Quote

Sounds good; thanks again,

John

Reply | Quote