Fatal Error debugging HResult=0x8007000e - by dipdip

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 296622 Comments
Status Closed Workarounds
Type Bug Repros 6
Opened 9/4/2007 10:31:45 AM
Access Restriction Public


I have a .net 3.0 solution in VS 2005 Professional with SP1 with about 70 projects.  I receive the following error every time i start my project in the debugger.

"A fatal error has occurred and debugging needs to be terminated.  For more details, please see the Microsoft Help and Support web site. HRESULT=0x8007000e. ErrorCode=0x0."

The solution contains two startup projects.  The first is a server which is a console app and the second is a winforms client.  A few of the projects are common class libraries which are referenced by other projects.  The bulk of the projects are plugins to the system that are dynamically loaded at runtime into their own appdomains by the client and server.

I do not see the problem if I only run one of the projects through the debugger.  The client is loading about twice as many assemblies as the server.  I had heard complaints from other developers about this error a few times in the past, but it seemed random with low reproducibility.  Since last week, it happens nearly 100% for all developers.  Very rarely (< 2% of the time) there will be no errors)

I thought this might be related to out of memory, but I am running a very powerful machine with 4GB of RAM (3GB addressable in 32 bit winXP).  I have seen a couple of build time errors from msbuild which I thought might be related.  They are attached in a txt file.

I have attached a minidump from the time that this occurred

I have applied the hot fix for KB number 912884 which did not help.  
Sign in to post a comment.
Posted by Thiago Santos on 5/14/2014 at 11:56 AM
I'm experiencing this issue with VS 2012 Update 4
The project I'm running is a Web App that exposes a couple of rest endpoints as well. Aside from this, it has a class library for models and another for data access, in which I connect to SQL, CRM and GP, depending on the action.

This is happening to other people in my organization.

I wonder why this is marked as Fixed since there's a number of people still experiencing the same issue.
Posted by Gaurav Kumar Arora on 2/14/2014 at 9:55 AM

The status of this bug has been closed as fixed. I faced the same issue with VS2012 .net framework 4.0 using x64 windows 7 machine. I faced this issue with a simple console application, contained a single class which uses another solution class methods.

I am continuously getting this issue. I did not find any work around.

If there is any way/workaround for this, let me know.

Thanks & Regards,
Gaurav Arora
Posted by AdvanTiSS on 2/9/2011 at 5:02 AM
I've got same problem during debugging WCF service in VS 2010.
This error have become appears after I install JetBrains dotCover extension.
After disabling dotCover and restarting VS error did not appear again
Posted by Microsoft on 3/21/2008 at 11:00 AM
A fix for this issue has been created and will be included with the upcoming .NET Fx 3.5 service pack 1 release. Specifically, the debugger metadata for ngen'd assemblies in multiple AppDomains will now share virtual address space (it previously shared physical memory, but not VA). In our tests this makes a very significant improvement for scenarios like this one.

The performance of debugging a process with a large number of AppDomains is a scenario we'll focus on further for the next major release of the CLR (4.0).

Thanks again for reporting this and helping us to improve the quality of the CLR!

Rick Byers
Posted by Vicel on 11/30/2007 at 11:53 AM

I ran into the same problem. I have a solution with 34 projects, 11 of which are WCF web services and 1 is a website talking to the services. The solution works well with VS 2005. Now I'm trying to move it under VS 2008. Here the problem starts.

When I start only the website everything's fine, but when I'm trying to start the website and 1 or more services in the debugger I have the error. Surprisingly, I could access some of them until the error occurs in one of non-startup services.

I tried to set all webservices to startup and 7 of them threw the error .

I use a virtual machine (1200Mb) with Windiows 2003. The memory usage was about 1G
Is it possible that the problem is related to the virtual machine?
Posted by Microsoft on 10/16/2007 at 4:04 PM
I just wanted to update this bug with the most recent status. We are still in the investigation phase of providing a hotfix for this issue.

Posted by Microsoft on 9/28/2007 at 11:06 AM

Thanks again for notifying us of this problem. As we discussed in e-mail, the CLR team is investigating the feasibility of providing a hotfix for this issue. I'll keep you updated on our progress. Please feel free to reply to our mail thread should you have any questions or concerns.

Posted by Gregg [MSFT] on 9/21/2007 at 5:11 PM
I responded to Amar over email, but I am posting here in case anyone else hits into this problem.

This is a problem with the way CLR metadata is read during debugging. I will move the issue over the .NET Framework team to see if they could make an improvement in this space for a future version. For now, I can offer a two suggestions:

1. It would be possible to somewhat work around the problem by using the remote debugger. To do this:

a. Launch the remote debugger. In Amar's case, he is debugging two apps, so I would recond using two different instances of the remote debugger and give them different 'server names'. I will call them 'A' and 'B'. Server names can be customized either from the options dialog, or from the command line (C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\Remote Debugger\x86\msvsmon.exe /name a). I would also suggest using the '/nostatus' switch so that the remote debugger doesn't pop up any UI. If you regularly debug an app that has many app domains then you might want to add shortcuts to the 'Startup' start menu group so that these just run and you can ignore them.

b. Open properties for your launching project, and switch to the debug tab. Check the 'Use Remote Machine' button, and enter 'A@localhost' for one of your startup projects and 'B@localhost' for the other.

c. Now when you launch, the VM size of the devenv process stay within a reasonable level. While the VM size of each of the msvsmon.exe processes will continue to grow, I would expect for it to stay more reasonable since there isn't much else in the msvsmon.exe process. If you are trying to debug more than one process this would be especially true since there is now a separate process for each application you are debugging. Because this issue causes excess virtual memory usage instead of physical memory usage, as long as we can avoid running out of virtual memory then the cost in terms of overall system performance should be minimal.

2. If possible, you may want to consider reducing the number of app domains in your process. If you are running into this then clearly the current number is stretching the limit on what the debugging services current handles. Considering that most people debug their apps, this might imply that you may run into other more subtle performance problems with this number of app domains.

I hope this is helpful, and sorry for the issue,

Gregg Miskelly

Posted by dipdip on 9/18/2007 at 4:34 PM
Hi Jim,
We don't see the error when we are running outside of the debugger. It does appear that visual studio is running out of memory. I have attached a screenshot of the VM size of devenv.exe when the problem occurs. it is at around 2GB (1,990,712K). The vm size of my applications is 187,684K and 225,916K respectively.
The error occurs to all developers on my team, many of which are using generic mice with generic drivers. I have tried disabling my mouse driver anyway, and that did not help.

hopefully we can find a solution to this problem soon, as it is making it difficult to debug our solution.
Posted by Jim [MSFT] on 9/17/2007 at 3:09 PM

I took a look at the dump you provided, however, it's not enough to be able to tell what is happening. In particular, we need to determine whether it's VS or your application(s) that are apparently running out of memory. In either case we can generate the same error. So, I'd like you to run your scenario again, but this time when the problem occurs, take a look a the commit (or VM size) of "devenv.exe" and your launched processes. Let us know what it is for each.

I also noticed in the dump that there is a specialized input device (mouse?) driver loaded into the process. While I have no reason to believe that this is the cause of the problem you're running into right now, we recently ran into an issue with the driver from another brand of input device that did indeed cause a serious problem for the execution of any managed application. If possible, please disable that driver to rule it out as a possibility.

FYI, even with a 4GB machine, it's possible to legitimately run out of memory. Right off the top, all processes on 32-bit machines are limited to 2GB. Then beyond that there are other factors that can reduce the limit even more for a given allocation request by a process.

Jim Griesmer
Visual Studio Debugger
Posted by dipdip on 9/13/2007 at 2:49 PM
Hi Liz,
this problem became apparent recently as the number of projects in the solution increased, but it did occur before nondeterministically. The assemblies that are loaded into appdomains are loaded using AppDomain.Load(assemblyString). The types being passed between the plugin Appdomains and the main appdomain each implement a few different interfaces, but the implementations do not inherit from MarshalByRefObj currently (this means that a copy of the assembly is loaded in the main appdomain when the object is used).

i hope this helps. Also, I attached a dump if thats useful.
Posted by Eliza [MSFT] on 9/13/2007 at 2:35 PM
Hi amardeepsingh,

We are trying to reproduce your scenario by dynamically loading the assemblies by the host application into their own appdomains, which is different from what we tested. Is there any other details you can provide that would be beneficial to reproducing the error?

Thank you,
Visual Studio Debugger Team
Posted by dipdip on 9/12/2007 at 1:52 PM
We see the same problem on our entire team which has a range of machines from 3.4GHz P4 with 2GB ram, to 2x dualcore Xeons with 4GB ram all on XP SP2. We have already tried using Beta 2, and the problem still occurs. I am fairly certain it has something to do with the dynamic loading of assemblies at runtime. Most of the assemblies in the project are loaded by the host applications into their own appdomains, and this is usually where the problem occurs. Have you tried this? We are also coding with C# with visual studio extensions for .net 3.0 and SP1
Posted by Eliza [MSFT] on 9/12/2007 at 1:43 PM
Hi amardeepsingh,

Thank you for the feedback. We attempted to reproduce the error you were receiving without success. We tried to match your environment as closely as possible by creating a solution with over 70 projects with two start up projects; one console and one winforms applications. The solution/projects were written in C# on a 3 GHZ machine with 2 GB’s of RAM.    At this point we would suggest that you try your scenario with Visual Studio 2008 Beta 2. if you continue to see this error on Beta 2 it would be beneficial to have more detail about your solution.

Thank you,
Visual Studio Debugger Team
Posted by Microsoft on 9/4/2007 at 5:29 PM
Thanks for your feedback. We have routed this issue to the appropriate group within the Visual Studio Product Team for triage and resolution.

Thank you,
Visual Studio Product Team.