Exception thrown when opening resx files in the Editor or adding new resx files to project - by Dennis Myren

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 309804 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 11/12/2007 4:13:55 AM
Access Restriction Public



My Visual Studio 2005 Team Edition for Software Developers crashes when i try to open any resx file in a large solution containing approximately 15 projects(the projects themselves is not, though, very large).
If i try to open a .resx file in the Editor, the following message pops up instead of the list of resources in the file:
"The type initializer for 'Microsoft.VisualStudio.Editors.ResourceEditor.ResourceEditorView' threw an exception."
Then Visual Studio is immediately crashing, the dialog says "Microsoft Visual Studio has encountered a problem and needs to close."
If i click the "What information is contained in this report?" link i get this error signature:
EventType : clr20r3     P1 : devenv.exe     P2 : 8.0.50727.762     P3 : 45716759
P4 : system     P5 :     P6 : 461ef191     P7 : 5a2     P8 : 0     
P9 : system.typeinitialization     
The same error occurs when i add a resource file to a project, using Add->New Item...->Resources File.

To generate the strongly typed resource classes, i need the designer to work properly.
I am getting around it partly by not using the editor, but rather XML directly, and partly by delegating resource check-ins to my colleagues...
But its quite frustrating.
Sign in to post a comment.
Posted by Dennis Myren on 3/19/2008 at 10:14 AM

Thanks for reply.

I have been running VS 2008 since BETA now, and have not been able to reproduce this error in that environment.
I will let you know in case i will be able to reproduce this again.

dennis myren
Posted by Microsoft on 3/19/2008 at 9:23 AM
Hello, we've tried create a VB solution with 50 projects (each project contains 20 files) and a C# solution with 19 projects (each project contains 32 files), and can't get it to repro in Visual Studio 2008 RTM (WinXp and Vista). Have you tried VS 2008 RTM? Since we were able to fix the crashing issue, I'm going to close this for now. If you do get it to repro on VS 2008, please reactivate it. Thanks!

-Noah Coad
Visual Studio Platform Program Manager, http://coadblog.com
Posted by Microsoft on 11/28/2007 at 11:06 AM
I think you are right. The static initializer of the resource editor loads some framework types (and assemblies), and initialize some arrays. OutOfMemoryException could explain why this happens.

I opened a seperated bug to track the NullReferenceException, which causes VS to crash directly.

I will forward this issue to the VS editor team, who owns the bloated table in the .suo file. The problem was reported before, but they have never found the root reason.

Thank you a lot, and you are very helpful for us to locate the problem in the product.
Posted by Dennis Myren on 11/28/2007 at 10:58 AM
Maybe its just out of memory.

System.OutOfMemoryException was actually thrown occasionally during this period, and VS would crash.

A designer might require some fair amount of memory. Loading a designer would cause the designer to load its resources, and the memory problem could occur at that point.
Posted by Microsoft on 11/27/2007 at 3:09 PM
It is strange to me that this call stack has nothing to do with the resource editor, which was in Microsoft.VisualStudio.Editors.dll. The call stack belongs to the background process of the XmlEditor. I wonder that exception might just happen in that call stack by a chance, and might be not the one causing the designer failed to load.
Posted by Dennis Myren on 11/27/2007 at 3:17 AM
OK, sorry, i misunderstood, i almost thought we were into something there... :)

Earlier i ran VS2005 side-by-side VS 2003, but not anymore.
Now, i run VS2005 only at work.

At home, i use VS2008(BETA still) side-by-side VS2005, and usually i use VS2008 at home to edit
files that belongs to a VS2005 project on another machine.
But as i said earlier, i transfer only source code files between machines anyway so it should not be a problem.

I think i have got the dump file right this time.
I opened another instance of VS, and in Debug->Exceptions i checked "Thrown" for System.TypeInitalizationException,
then i attached to the instance running the solution, and produced the exception.
The debugger halted on System.TypeInitializationException, and i breaked
and saved a dump file from Debug->Save Dump.
The zip file contains a version with heap data, and a version without the heap.

You may download this file from here:

dennis myren
Posted by Microsoft on 11/26/2007 at 5:19 PM
Thank you a lot for you to give us the crash dump file. With that dump file, I found out the direct reason of the crash. It looks like the first exception, which you saw in the designer surface, causes some intialization code in the designer framework to skip. Although that exception has been taken care of, skipping some important logic causes a NullReference issue in a later event, which brought down the whole IDE.
It is still not clear to me why we get the type initializer exception in the first place. I guess it is related to the bookmark, but don't know how. That exception should happen when a static class initializer fails, but there is little code there. When you have time, could you help to catch a dump file when that exception happens, so we can find out what is going on there? To do this, you need start another VS, and attach (debug) to the another running VS. You need attach to debug both managed and native code, and set the debugger to stop on TypeInitializationException, then try to open the resource designer to repro this issue. When the debugger catches the exception, you can save a dump file.

Thank you a lot to help us to improve the quality of the product.
Posted by Microsoft on 11/26/2007 at 4:07 PM
Sorry for the miss-leading information. I don't think that VS would keep text for normal bookmarks. But the shortcut does keep the text as default name of the shortcut, which could be edited. I will try to find developer of that area to take a look at this issue.
I wonder some operation might cause exisiting shortcuts to be duplicated. As you said, the huge .suo file stays the same size when you closed the project. That sounds that we didn't hit the operation causing that. I saw some reports on VS2003 about this, but not for vs 2005. Did you work on that project on VS 2003 on the same machine?
Posted by Dennis Myren on 11/26/2007 at 11:14 AM
I have not used a such TaskList function, AFAIK.

I am happy when you say that the content of the book marker is copied from the code,
because i now understand how VS internally keeps track of bookmarks.
I have noticed earlier, and wondered about the fact that
setting a bookmark in VS, means setting a bookmark at that current instruction(or fragment, that is),
rather than at that current line number.

And I do use bookmarks, so there is a possibility that this code line(fragment)
may have been bookmarked while i was performing this global find-replace operation...

Whenever i get the time, i will create a heavy solution and mess with it, to attempt to reproduce the exception.

If i am ever able to reproduce this exception consistently, then ill be back!!

dennis myren

Posted by Microsoft on 11/26/2007 at 10:12 AM
I was wrong. The oversized section is actually not related to breakpoints, but "TaskListShortCuts", a kind of bookmark stuff. The content of the book marker is copied from the code. However, it won't be updated even the code has changed or been deleted, and the task list item will stay. I don't know how this list exploded. Did you ever create TaskList short cut for this code line, or use this function?
Posted by Dennis Myren on 11/22/2007 at 2:14 AM
Yes, I noticed the repetitive pattern in the suo file.

As far as i remember, i dont think that i have ever set a break point on that very code line(since this project is very new, i think i would have remembered).
I do remember this code line was involved in some global search-replace operation, and that code line, as it appears in the suo file, does not exist anymore.

But i am sorry, i do not have a further clue to what may have caused the corruption. If i do come up with something, i will let you know.

I have been able to temporarily publish the dump file to a web site, it will be available there for a limited time(like a week), so that you will be able to download the dump file during this period.
Download it from here:

I hope this file will give you some clues.

Regards Dennis Myren
Posted by Microsoft on 11/21/2007 at 9:29 AM
Thank you a lot to upload the .suo file. What I found is that a same piece of data was repeated numberless times in that file, and it was most of the file about. (If you open it in a binary editor, you will see that pattern.) The rest of the file seems normal.
The repeated part of the file looks like this:

\..\Net-Lib\Bluegarden.Data\DatabaseRegistry.cs!n    private static object threadLock = new object ( );

I'm not sure what it is, but I doubt that looks like a breakpoint saved. I saw someone mentioned an issue online (http://www.compuware.com/breakpoints/), which I think is related to this issue.

The connection web site limited file to 2MB. A possible workaround is to open a temporary live space and upload the crash dump file there. Is this possible?


Posted by Dennis Myren on 11/20/2007 at 1:08 AM
Hi again,

I was able to load the solution this morning using the corrupt .suo file.
I have zipped the suo file down to a 350KB zip file and attached to this feedback item.

I have also created a dump file, and the zipped version of the dump file was 150MB.
I tried to upload this item, since you have a big 200MB upper file size limit.
But i am afraid i got a server timeout on that one.
If you really want this file, is there any other way i could send it ?

Posted by Dennis Myren on 11/19/2007 at 12:21 PM
Thanks for quick feedback,

I will try to load the solution at work tomorrow using the 35MB suo, i backed it up before deleting from solution.
In any case, i will attempt to attach the suo file here tomorrow.

Meanwhile, i can answer your questions;
>1, are your projects managed by a source control?
Yes, we are using Team Foundation Server.
This is our first big project using Team Foundation Server for source control, we migrated from SourceSafe couple of months ago.

>2, when you open the solution with the corrupted .suo file, did VS open a large number of files?
No, it dont. It remembers, correctly, to open those files that were open when the solution was last closed.

>3, did you ever copy the .suo file from another machine?
No. I do copy source files back and forth on a regular basis, but only selected source code files.
I then paste these into the solution; i dont transfer solution or project files unless i need to, and i wouldnt transfer the suo, since it is just user settings.

See you soon
Dennis Myren
Posted by Microsoft on 11/19/2007 at 11:10 AM
It is great that you find a workaround for this issue. Hope you won't get into this problem again.

We saw several reports about a huge and corrupted .suo file, although the root reason of the problem hasn't yet been found. You can see some similar reports here:

The .suo is a file with open format, which allows different packages in VS to save information like files which should be opened when you open the solution, and all breakpoints and watch window expressions. It is somewhat difficult to say what goes wrong. VS also open files files based on this file, so it might open a designer which causes problems.

It is tough to fine out the reason without a repro. Could you help us several things, so we can do some investigation?

First, could you answer a few questions?
1, are your projects managed by a source control (like visual studio sourse safe)? what kind of source control you are using?
2, when you open the solution with the corrupted .suo file, did VS open a large number of files?
3, did you ever copy the .suo file from another machine?

Second, could you zip (winzip) and attach the corrupted .suo file?

If you can reproduct the crash senario, could you create a dump file, and attach the dump file?


Posted by Dennis Myren on 11/19/2007 at 4:07 AM

Another problem i have had for the past few weeks is that Visual Studio usually spent at least 5-10 seconds
each time i saved a file i the IDE, regardless the size of the file(s), and often up to 20 seconds.

I did not mention this in the current bug report, because i thought this problem
was in some way related to our Team Foundation source control, i did not think these two problems were related.

I followed the steps in Jeff Abrahams blog to delete all items from the ProjectMRUList/FileMRUList
registry settings;
But still, Visual Studio spent loads of time saving small source files(Visual Studio freezes during this period, and is not idle).

Today, i decided to run Filemon to attempt to track down a Visual Studio File->Save All(CTRL+SHIFT+S) command.
I immediately noticed that the solution's auto-generated Visual Studio Solution User Options file(*.suo, located at solution root)
was written to thousands of times for each save, maybe around 10000 times!
I looked at the size of this file, and it was 35MB!
Meanwhile, my colleagues, who develop on the same solution,
their respective .suo file had an average size of 150KB..

First, i just deleted the .suo file, while VS was still running, and saved again.
The file was regenerated to a size the same as before(35MB), and the number of writes to this file was as many as before; that is, thousands.
I then closed VS and removed the file, and then opened the solution again in Visual Studio and saved the solution.
The .suo file now went down to 99KB, and my saves are faster than ever!

And now, after deleting this file, VS works great again;
Resources editor, Add->New Item->*, it all works as expected!

So i guess i found the solution, but i cannot explain why this suo file was so big.
Without knowing, i would still guess that there is a connection between large projects, and making lots of changes in large projects, such as deleting projects, adding and changing projects, and do some other heavy find-replace stuff.

So rather, that was the original bug, and all problems i have had with the editor, was due to this i am guessing.
I will have the suo file available for you on request.

Dennis Myren
Posted by Microsoft on 11/12/2007 at 11:53 PM
Thanks for your feedback.

We are escalating this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.

Thank you,
Visual Studio Product Team
Posted by Microsoft on 11/12/2007 at 6:21 PM
Thank you for your feedback. We are currently investigating. The investigation process normally takes 7-14 days. If this issue is urgent, please contact support directly (see http://support.microsoft.com).

If at any time your issue is closed unsatisfactorily, you may edit your issue via Connect and change the status to “Active.”

Thank you,
Visual Studio Product Team
Posted by Dennis Myren on 11/12/2007 at 6:03 AM
A few hours later, Visual Studio has now seemingly disabled the "Designers Package".
When i try to open a resx file now, i get the node contents of the XML file as direct text, and a message in the output window that states the following:
"The Visual Studio Settings and Project Designers Package ({67909B06-91E9-4F3E-AB50-495046BE9A9A}) did not load because of previous errors. For assistance, contact the package vendor. To attempt to load this package again, type 'devenv /resetskippkgs' at the command prompt."