I have a vb.net project which sometimes, when running in the IDE, suddenly hangs. Normally this wouldn't be a problem. Just hit 'pause', look at the currently running threads, and find the deadlock (or whatever else).
But now I'm running into a situation where not only does the program hang, but trying to pause it causes visual studio itself to hang. In order to get control back, I have to kill the program-being-debugged's process, at which point visual studio comes back to life and says it was unable to pause execution. This is frustrating, because killing the process means the program state is lost (of course), so I don't know where the hang is.
So are there any common causes for this behavior? What should I be looking for?
if your program installs global hooks (which communicate with app) - this might be the case. A hook tries to communicate with your app (which is paused by debugger) and gets locked. And debugger is unable to receive its window messages: classic deadlock between hooked debugger (with hook dll) and a hooking app.
Finding a specific fix for a Visual Studio problem can be tricky: http://social.msdn.microsoft.com/Search/en-US/?query=visual%20studio%202008%20hang&ac=3
Additionally, not all hotfixes from Microsoft get released directly to the public. Some are only given out to customers whose systems are exhibiting a specific problem. So you have to contact Microsoft to the get the fix. They do this to limit the potential downside of releasing a hotfix that may break something else. So if all else fails, give them a call.
Here are some other things that I like to do when Visual Studio starts acting up:
Delete old breakpoints and watch variables.
With visual studio not running, delete the intellisense file (.ncb)
Clean the solution and then do a rebuild of all of the code.
Check hotfixes and service packs. I've seen a bug related to .net programming and debugging hangs. (VS hangs for me when debugging C++ 32-bit apps on 64-bit os:es sometimes.)
I just had a very similiar issue (VS fails to break execution), using Debug -> Delete all breakpoints solved the issue.
I'd check the code of the program being debugged, I'm thinking there may be an infinite loop or race condition in the code you're trying to debug. This has been the case for me in the past, especially on a single-core laptop I used to have. Can you give any information about where in the program you think execution is when you try to pause?
Related
The main software that we built is built using VB6 (old school, I know). We're having some problem for viewing a report using ActiveReports. We did many Debug DLLs and were unable to find why the problem happen. Note that restarting the server solves the issue, which brings us to think that the problem is resource related.
Is there a way I can see how much memory is being used by a DLL? I would like to see if an object in that dll might not be released correctly.
I tried using the performance monitor, but this is not as precise as needed.
Is there anything i could use to monitor a Dll's usage?
We are just doing it the hard way and monitoring a server running multiple instances of the DLL.
To nip this in the bud, I have posted this question and workaround. I would like to accept an answer that actually quantitatively describes the problem.
I do some office programming using VS2010 and VB.NET. I have found that using VB.NET over VBA provides a much better user experience for office automation tasks. But, VB.NET IDE sometimes, not all the time, grinds to a halt when debugging Excel COM interop code, such as it takes 5 minutes to set a string equal to the value of cell, or just removing and adding breakpoints takes minutes apiece. This has been the bane of my existence for sometime, as I would have to restart my computer to fix it, but I have finally figured out the causal actions and a workaround. It happens when I have more than one other Excel instance open besides the COM server. I know Excel usually only opens one EXCEL.EXE, but, I have my registry settings so that every excel document opens in a new instance, so that I can look at separate docs on separate monitors. I don't believe this is uncommon. So, when I have left Excels open and my app starts an Excel COM server and breaks into the debugger, this is when the problem occurs, but also only if I click or operate in someway in one of the Excels after starting the COM server. Then it is like the COM server gets confused as a chameleon in a bag of Skittles of which it can't get out until I restart the computer. So, does anyone have enough debugging, COM, and Interop expertise to tell me what is causing this debugging hell? And possibly a way to preempt it?
To workaround this problem without restarting, I have found that I can end all instances of EXCEL.EXE, even the COM server, and close the IDE, then reopen Excel directly without a document and close it. Now, reopen the IDE, run code, start debugging, and stepping latency is non-existent or negligible.
I work on a Classic ASP web application that uses several old COM components written in VB6. All of the VB6 components are registered in a COM+ application that run in their own dllhost process. A large majority of the application has been converted to .Net, but there are still a lot of legacy pages and components. COM Interop is used in both directions, calling some .Net assemblies from classic ASP and VB6 as well as calling VB6 components from ASP.Net. The application is running on Windows Server 2008 R2 (IIS 7.5) in the classic pipeline mode.
For the most part the application works fine. The transition to .Net effort was ultimately abandoned, with a new product being developed instead. In the meantime, the old product must be maintained in it's heterogeneous state.
I am having trouble tracking down an intermittent problem where the web application hangs. Users just see a blank screen while their browser waits and the server never responds. The hang persists until I manually kill the dllhost process that's hosting the VB6 components, so I believe the problem is buried there. Probably a memory leak or runaway circular loop.
There are thousands of users on the system daily, but the problem only happens once or twice a week. Fortunately we have a web farm that automatically pulls a server out when it stops responding, so the customer impact is zero. Still, I would like to figure out what's going on.
I have recompiled all of the VB6 components to include debugging symbols and redeployed to production. When the problem happens, I use the 32-bit task manager (c:\windows\syswow64\taskmgr.exe) to take a crash dump of the dllhost process. I end up with a dllhost.dmp file, which I bring down to my development workstation and open in VS2010. I have the .pdb symbol files that VB6 created in my symbols path. When I start the debugging session in VS2010, I can go to the Modules screen and see that indeed all of the symbols for my components are loaded.
Where to go from here? The call stack doesn't show any of my own components. It looks like this:
The disassembly at the top of the call stack looks like this:
Not sure what else I can do. I examined all of the locals at every frame of the call stack and it's gibberish to me. I don't see any references to any of my own components.
Perhaps WinDbg would yield more information? Not sure where to start with it.
I'm pretty sure that if I could just find what VB6 class/method was being called when the hang occurred that I could get to the bottom of it. I've tried adding some logging, and the results are inconsistent.
Perhaps there's nothing wrong with my VB6 components at all, but I'm hitting on some bug within Windows or IIS?
Any advice would be appreciated, but throwing away VB6 is not an option at this point. Thanks.
Not a complete answer, but CoRegisterSurrogateEx is documented to block as long as the surrogate process is running:
The CoRegisterSurrogateEx function is a blocking function. It does not
return until COM+ has determined that the process will be shut down.
Before calling this function, initialize COM on this thread as a
multi-threaded apartment (MTA).
So I don't think the error is on this call-stack. (You can see it was still blocking on a WaitForSingleObject call, most likely the mechanism it uses to block until the process is to be shut down).
I am porting VB.Net 2 code (VS 2005) to VB.Net 4 (VS 2010). So far things have been going relatively smooth. However, in testing my new ported code, I came across a strange behavior.
In VS 2005 (.Net 2), I have a DataTable filled with data. I then use a DataAdapter to send updates back to the SQL Server. When I perform the SqlClient.SqlDataAdapter.Update() command, it execute in roughly 4 seconds. The same code, on the same table in VS 2010 (.Net 4) runs in 1 Minute 17 Seconds. This is completely unacceptable. However, I have no clue as to why it is happening. The .Update() method is an internal command, not one that I modified in any way. It does not error out, it's just painfully slow.
Anyone have any ideas?
After many months of working directly with Microsoft...a solution/answer was found.
I don't feel so bad because it took six different Microsoft programmers and almost six months of time to discover the answer. Apparently, Visual Studio 2010's IDE behaves significantly different than it's Visual Studio 2005 counterpart. When running an application in the IDE, VS2010's hook into the running executable actually hinders the applications performance considerably. There is a hidden option (not found in the menu structure) to run the application without the debugger attached. The hotkey is CTRL+F5. When the application is run in this mode, our performance issue vanished. It's such a silly and simple answer...but the two things that make me feel better is that VS2005 did not have this issue, the "run w/o debugger" options isn't listed in the menu at all, and it took six Microsoft programmers to determine this was the issue.
So for anyone else that seems to have this same issue...try CTRL+F5. :-)
We have 3 developers all using the same version (VS 2008 SP1) and we all use large VB projects (windows forms). From time to time, the IDE will have all sorts of issues such as locking up, crashing, and even not being able to drag a form object around or it will just instantly disappear.
On the largest of our projects (which is actually 5 projects in one solution file), a couple people here can only rebuild the project for testing 2 - 3 times before they have to close the studio and reopen it.
Has anyone else experienced this? Does this happen with large C# projects?
Yes, I experience this all the time! It has gotten better in 2008, if you can believe it.
I usually find that the reason has to do with an exception in my own code. The UI might bring in a custom control that does not behave well in design mode, causing the problem.
Sometimes, I will bring up a second execution of VS2008 and attach the debugger to the first execution of VS. Then, I can debug my own code as it is being run in the designer of the first instance. Often, an exception is thrown and I can fix my code to play better in the designer.
In other circumstances, I have no idea why it happens.
I have heard of people having this issue, however, I have never had an issue at all myself.
I have heard that a number of people trace the issues back to the use of ReSharper as the primary cause.
The most common problem I've had that causes the designer to crash is when I create a form where the only constructors require parameters.
To alleviate that, when I need the form only to be instantiated with parameters, I create a private parameterless constructor that the designer can use but which the form's consumers won't see.
I have personally experienced all sorts of designer wickedness with VS2008 sp1. I uninstalled the service pack to return stability to my dev environment. This is an unfortunate answer, but give it a try.
Only thing I've had close to this is the design view crashing and bringing up an error, formerly causing me to have to recreate the form and copy and paste the code across until I learnt how to fix it.
My problem was occurring because of me using ctrl+f a lot though. If you are using big files, this might be what's happening.