Search

Loading toolbox content from package takes 55 seconds or more by Daniel Carey

Closed
as Not Reproducible Help for as Not Reproducible

87
0
Sign in
to vote
Type: Bug
ID: 551183
Opened: 4/14/2010 2:33:45 PM
Access Restriction: Public
6
Workaround(s)
56
User(s) can reproduce this bug
Visual Studio 2010 RTM loads quick when the toolbox panel isn't expanded. The first time the toolbox panel is viewed, the status base says "Loading toolbox content from package 'Microsoft.VisualStudio.IDE.ToolboxControlsInstaller,ToolboxInstallerPackage'{2C298B35-07DA-45F1-96A3-BE55D91C8D7A} for about 55 seconds.

I followed the suggestion to clean out %USERPROFILE%\AppData\Local\Microsoft\VisualStudio\9.0) (for \10.0) from here : http://social.msdn.microsoft.com/Forums/en-US/vswpfdesigner/thread/97d360a3-09d5-4839-80b7-1ab370011540/

This machine has had both Visual Studio 2010 Beta 2 and RC. Uninstalled Beta 2 before RC, uninstalled RC before RTM.
Details (expand)

Product Language

English

Visual Studio Version

Visual Studio 2010

Operating System

Windows Server 2008

Operating System Language

English

Steps to Reproduce

Start Visual Studio
Select View + Toolbox

Actual Results

45 sec wait.

Expected Results

< 4 sec wait.
      You can indicate your satisfaction with how Microsoft handled this issue by completing this quick 3 question survey.

 

File Attachments
File Name Submitted By Submitted On File Size  
VS2010RTM_Toolbox_Issue.png 4/14/2010 56 KB
Debug.zip (restricted) 4/29/2010 -
Sign in to post a comment.
Posted by Andrew Skalkin on 7/25/2012 at 11:48 AM
Worked for me as well!

http://michaelcrump.net/fixing-a-broken-toolbox-in-visual-studio-2010-sp1
Posted by avhzn on 7/21/2012 at 3:03 AM
Hello, the fix provided here, really worked for me!

http://michaelcrump.net/fixing-a-broken-toolbox-in-visual-studio-2010-sp1

Best regards,

Arjan van Huizen
Microsoft .NET MVP
Posted by r.guerzoni on 7/12/2012 at 1:54 AM
I have this problem too. Why the issue is closed. Please provide some solution.
This kind of problem is boring
Posted by vim on 6/26/2012 at 9:08 AM
I have this problem too. Why the issue is closed. Please provide some solution.
Posted by lymber2 on 6/19/2012 at 5:49 PM
i also have this problem. My third party controls were duplicating each time VS 2010 started. It is caused by the WCF RIA Services Toolkit (September 2011). Once i uninstalled this, then the controls would not duplicate. Please fix this issue
Posted by NickLP on 6/14/2012 at 3:34 AM
I also have this problem
Posted by happycoderjx on 6/7/2012 at 7:48 AM
Not to pile on, but this issue should really not be closed.
Posted by Khalilo1 on 5/23/2012 at 8:14 PM
Why on earth is closed as Not Reproducible, please do open it there again.
Posted by moondaddyx on 5/21/2012 at 8:37 AM
I installed Silverlight5_Tools.exe and now my solutions take 3+ minutes to open, and all 3rd party tools in the toolbox have 3 instances of each item. This seems very bad and irresponsible of MS to not address it. this is killing me as I work out of many solutions at the same time, and I’m hesitant to start deleting registry keys unless I can see formal documentation instructing me exactly what to do for the SL5 issue. MS, please respond.
Posted by DavidAir on 5/15/2012 at 7:36 AM
There is another connect bug which seems to be related:
https://connect.microsoft.com/VisualStudio/feedback/details/634314/extreme-startup-time

It directly links the issue to the installation of the Silverlight SDK and recommends deleting a different set of registry keys. Having followed those instructions, I'm now down to only 10 seconds of "loading toolbox content".

I think that in general, this is the issue of additional components polluting the toolbox. It would be *really* nice to know how the Toolbox Installer looks for those so that users could scan those locations and decide for themselves if they want those toolboxes or not!
Posted by Vanderlei Arruda on 5/11/2012 at 6:46 AM
can re-open this topic ? i have the same problem.

how i can fix it ?
Posted by slodge on 5/9/2012 at 2:33 AM
Same as Berney - this happens all the time now after VS11 install.

This is a minute or more of downtime on a fast 8gb ram, 256GB ssd, quad core i5 machine... please fix it...
Posted by Berney on 4/15/2012 at 8:25 PM
This never happened to me, but started happening in VS 2010 after I installed the 11 Beta!
Posted by ColoradoMan on 4/13/2012 at 1:38 PM
I'm having the problem as well... I have vs2010 sp1, Win 7 Ultimate 64. I tried Dimitri Kampouris' work around posted on 3/21 and seems to be helping so far.
Posted by gpk13 on 4/2/2012 at 7:29 AM
P.S. I have: Silverlight & WPF toolkits & SDKs, Telerik 3rd party control for both.
Posted by gpk13 on 4/2/2012 at 6:27 AM
This is NOT a closed issue and is fairly reproducible; please reopen.
Posted by Ron Frick on 4/1/2012 at 2:12 PM
I have the same problem. They should re open this one!!!
Posted by Igor Golovin on 4/1/2012 at 7:42 AM
Meantime i have installed Visual Studio 11 Beta and it have same problem when opening XAML designer, it takes time t load, but it does not show status (only progress bar window). Takes up to 30 seconds sometimes.

I've tried all workarounds from here, the problem disappeared for a while and the apears again...
Posted by dirq on 3/28/2012 at 1:24 PM
I have the same problem. Have had it for awhile. Win7 Pro 64. VS 2010 SP1.
Posted by Igor Golovin on 3/26/2012 at 8:18 PM
Gyus, reopen this bug!
After performing workarounds i faced with that issue again. It's so annoying.
Posted by Rob Ainscough on 3/14/2012 at 9:33 AM
After installing SL5 developer tools, I started getting this message and long delay also.

Who closed this and why?? It's unlikely Microsoft are going to fix this and from what I can see the same bug is in VS11 Beta ... again, one more reason to avoid using Microsoft's tools. I guess "Mark" has moved on to other projects with bigger bonus potential at Microsoft since we've no heard any more and this bug has NOT been addressed.
Posted by Pete BSC on 3/14/2012 at 7:51 AM
After installing Visual Studio 2011 BETA, I am now getting the "Loading toolbox content package .... " loading lag.
Posted by Maximilian Haru Raditya on 3/6/2012 at 4:14 PM
This experience is better in VS11 BETA, compared to VS2010 SP1. So far, I never experienced this kind of issue. It seems they have improved it.
Posted by Josh Stevens on 3/6/2012 at 1:36 PM
For all who are experiencing this issue, please try removing the "Toolbox" registry key from the following locations (if present):

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Silverlight\v4.0\AssemblyFoldersEx\Ria Services v1.0 Silverlight Libraries

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Silverlight\v5.0\AssemblyFoldersEx\Ria Services v1.0 Silverlight Libraries

(If running 64-bit Windows, insert "Wow6432Node" after "Software" in the registry paths.)
Posted by Rodney Foley on 3/6/2012 at 9:30 AM
Why is this bug closed? 28 people including me can reproduce the issue.
Posted by GEDP on 3/1/2012 at 3:12 AM
Maybe this is related to the OS version? I had the problem on Windows 7 Professional 64 bit.
Can you post your OS version here? Maybe we will a a pattern then...
Posted by Eckard Meyer on 2/21/2012 at 11:10 PM
After the Silverlight 5 install I had the same problem, and followed the workaround for deleting the Registry Key(s), and that has worked fine. I am running Visual Studio 2010 Ultimate with SP 1.
Posted by DavidAir on 2/3/2012 at 10:09 AM
It does feel like it happened only after Silverlight 5 install. Tried the registry hack and it seemed to have fixed the problem temporarily - but now it's back. Extremely frustrating!
Posted by Isaac Abraham on 1/29/2012 at 2:54 PM
Not reproducable - so that 30+ people that reported this must be imagining it.
Posted by GEDP on 1/25/2012 at 12:22 PM
Igor,
Have you tried my suggestion of uninstalling RIA services 1.0 SP2 (See my post of 29/12/2011)? If so, what are the results?
Geert
Posted by Igor Golovin on 1/25/2012 at 5:24 AM
reproduced after SL5 install
Posted by ronnieoverby on 1/18/2012 at 6:42 AM
I can't take this anymore! Everytime I open and designer in visual studio (edmx, xaml, winforms, wf4, you name it) I have to wait 3 minutes because of this. I'm sick of it. FIX IT.
Posted by AFM56 on 1/16/2012 at 5:33 PM
As of Jan 16, 2012:
Substantial delay on VS 2010 initial opening caused by: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VBExpress\10.0\Packages\{2c298b35-07da-45f1-96a3-be55d91c8d7a} continues.

When I attempted to close VS 2010 during this delay, I received the VS2010 not responding message box .... and I did "Send" dump to Microsoft. This problem did not exists yesterday for me and can't remember if any Windows Updates or Extension Manager updates were performed. You can direct MS team to look for the following dump on 1/16/2012:

Description:
A problem caused this program to stop interacting with Windows.

Files that help describe the problem:
C:\Users\Art.HOMEOFFICE\AppData\Local\Temp\WERF51A.tmp.hdmp
C:\Users\Art.HOMEOFFICE\AppData\Local\Temp\WER205F.tmp.xml

Posted by GEDP on 12/29/2011 at 2:01 AM
Hi,
I had the same problem after installing SL5. The side effect was that some third-party components were duplicated in the toolbox each time VS was started.

I noticed that SL5 Tools for VS also installs RIA Services 1.0 SP2. As there were already some hints that RIA caused simimar problems in the past, I decided to uninstall that one. I also reset the VS toolbox and deleted the *.tbd files. The next start of VS took some time (rebuilding the tbd files) but since then, VS startup is smooth and I have no duplication of toolbox items anymore...

Posted by juFo on 12/20/2011 at 12:58 AM
This problem occured first after installing Silverlight 5
Posted by juFo on 12/19/2011 at 6:53 AM
I'm just opening visual studio 2010 (no solution is opened)
The toolbox was visible but takes ages to load... (several seconds)

I see this at the bottom:
....olsInstaller.ToolboxInstallerPackage' {2C298B35-07DA-45F1-96A3-BE55D91C8D7A}
Posted by Jerry T on 11/22/2011 at 6:51 AM
I get this when I hit the Esc key once or twice while in a XAML file. Takes about a minute before VS 2010 is responsive again.

Did the registry key delete and that helped some. Hitting Esc in a XAML editing window still takes about 20-30 seconds before VS is responsive again.
Posted by Juan Segura on 10/2/2011 at 11:58 AM
The alternate solution suplied by Daniel Carey works for me:

Backup the registry and delete all keys with "2c298b35-07da-45f1-96a3-be55d91c8d7a"
Posted by Deva Wijewickrema on 8/1/2011 at 4:43 AM
I also have the issue on my newly rebuilt hard drive, I am running VS 2010 ultimate, sp1
The issue for me occurs the first time vs load's the first sln. After that if I close the sln, and reopen it it comes up much faster...

I am stting on the "Loading toolbox content from package Microsoft.VisualStudio.IDE.Toolbox.ControlInstaller.ToolboxInstallerPackage
'{2C98B35-07DA-45F1-96A3-BE55D91C8D7A}'"...

if you need any debuging info let me know, I will also be emailing Mark with this information.

Posted by MawashiKid on 6/26/2011 at 9:49 AM
Hi Karabash
I guess you're right about VS synchroneously loading ALL registered toolbox content from ALL installed toolkits during startup process. I'm afraid that won't be solved that easily...
I experienced the same issue though it wasn't related to Infragisitic 2009 toolkit in my case.
I work mainly on WPF 4 and Silverlight 4 projects
and use 3rd parties tools. All toolbox components would always load up in a snap, nicely all piled up
in their corresponding tab. I never encountered any issue using Visual Studio 2010 RTM up to recently.
All projects and reference dll files would load properly in Solution Explorer, though whenever I enter in XAML code area of a file,
same redundant long process would start over and over again.

Loading toolbox content from package Microsoft.VisualStudio.IDE.Toolbox.ControlInstaller.ToolboxInstallerPackage
'{2C98B35-07DA-45F1-96A3-BE55D91C8D7A}'...

I first tried a toolbox reset, though that didn't change anything. Not only that, what was previously a clean
process became pretty blurry...I couldn't tell which component was which... Ouuuuuuuuuuuch!
Something really messy occured here and I didn't waste any time to try to clean it up.
I first ran a log (devenv /log c:\myIssueFolder\ideLog.txt)
in order to try to focus on what might be the source of the issue here...

<entry>
    <record>464</record>
    <time>2011/06/16 16:58:24.945</time>
    <type>Information</type>
    <source>VisualStudio</source>
    <description>Entering function CVsPackageInfo::HrInstantiatePackage</description>
    <guid>{2C298B35-07DA-45F1-96A3-BE55D91C8D7A}</guid>
</entry>
<entry>
    <record>465</record>
    <time>2011/06/16 16:58:24.957</time>
    <type>Information</type>
    <source>VisualStudio</source>
    <description>Unexpected system error mode before loading package [Microsoft.VisualStudio.IDE.ToolboxControlsInstaller.ToolboxInstallerPackage]</description>
    <guid>{2C298B35-07DA-45F1-96A3-BE55D91C8D7A}</guid>
</entry>

But the question here was what exactly might have been the real cause of the system error issue.
I keep a track of everything I install with time and date.
The only thing I installed were Telerik JustCode followed by WCF RIA Services Toolkit April 2011 version.
I proceeded by first removing WCF RIA Services Toolkit April 2011, then
reopen VS 2010 and everything came back to normal.
Ran another log and error message was gone... Hmmmm...
Strange indeed...
Posted by Karabash on 6/16/2011 at 5:19 AM
Hi there, I have had the same problem for quite some time. Obviously, it is cause by VS synchroneously loading ALL registered toolbox content from ALL installed toolkits during startup. I de-installed the Infragistics 2009 toolkit as well as Silverlight 3 (left SL4 in place) and -voilá- the problem was gone.

I a afraid that this is not a thingie that can be solved that easily by the VS developer team, as they do not have any influence on how many million items some 3rd party vendor attempts to squeeze into the toolbox(es)... THus, it might be a solution for a later update to
-- decouple the loading of the toolbox(es) from the VS bootstrap and push it into a separate task, running in the background
-- provide some tooling for toolbox developers to let the developer decide during VS runtime, which toolboxes s/he wants to use and needs to be populated
-- have some 'intelligence' at hand which decides about the previous step automatically

Surely, all of these suggestions cannot be realized on-the-fly... but maybe we'll see an update in a year or two? *grin*
Posted by Igor A. Vyatkin on 6/10/2011 at 4:59 AM
A can reproduce this problem with VS2010 SP1. How can I help MS to fix this issue?
Posted by The first MaYHeM on 5/26/2011 at 11:26 AM
Closed? Lame!
Posted by Maximilian Haru Raditya on 3/10/2011 at 5:19 PM
Have you tried resetting the toolbox? I used to experience this issue with WPF apps, but not anymore after I reset it. It only happens now less than a second, and almost unnoticeable, both for WPF and Silverlight apps.

I'm using VS2010 SP1 RTM.
Posted by mel1daa on 3/8/2011 at 11:51 AM
This is happening to me as well just like ICP-Fan. It also takes longer and longer and I end up deleting the .tbd files in the VisualStudio AppData folder and that helps - but then it just starts all over. Longer and longer wait times. I deleted the {2C298B35... key from the registry and that instantly fixed the problem. However, when I opened a Silverlight project it said I needed to install the Silverlight 4 toolkit.

I agree. Please re-open this item.
Posted by ICP-Fan on 2/18/2011 at 1:24 PM
I get this every time I open my toolbox while working on Silverlight 4 applications. The larger the application, the longer the wait. I basically open the toolbox after the solution loads and go grab a soda. By the time I get back, It's finally done loading. Everyone I work with complains about it.

This one needs to be re-opened.
Posted by Davide Icardi on 2/8/2011 at 4:36 AM
I have only removed the key:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\10.0\Packages\{2c298b35-07da-45f1-96a3-be55d91c8d7a}]

and now the toolbox start up immediately.
Posted by IngoRammer on 1/26/2011 at 4:20 AM
I'd like to second Pomel here. The problem continues to occur on my main dev machine.

-Ingo
Posted by Pomel on 1/11/2011 at 10:22 AM
Can this bug be re-opened?

I see that 4 other users including myself can reproduce this bug.
Mark, I sent you an email as you requested in the prevoius comment with my contact info.
Please let me know what information I can provide to help you to correct this bug.

Scott
Posted by Microsoft on 6/7/2010 at 2:40 PM
Hi WHawke

Thanks for letting us know and providing the additional details.

Unfortunately there isn't any useful information in the debug output you provided. Since you are no longer experiencing the issue, I am going to close this bug; however if you (or other readers of this bug) see this issue again please email me mwthomas at microsoft dot com quoting connect ID 551183 and I will reopen the issue for further investigation.

Mark
Posted by Daniel Carey on 4/29/2010 at 6:32 AM
I am no longer experiencing the problem.

I have had the following silverlight developer versions loaded on this computer.
3.0.40818.0
3.0.50106.0
4.0.50401.0

I'm attaching a Debug.zip file that contains my screen captures, notes, and the registry entries.

The screen capture file "VS2010RTM_Toolbox_Issue.png" shows the status bar. The message indicated a problem loading the package with the GUID {2c298b35-07da-45f1-96a3-be55d91c8d7a}.

One of the first things I tried was to launch Visual Studio, then attach to another instance of Visual Studio while it was starting up. I've attached the contents of that output as file "Toolbox Output Window.txt". I wasn't able to get much insight from the information but it may be of use to you.

I considered that if Visual Studio was having problems loading that particular package, I'd just remove it from being started by Visual Studio. I used regedit.exe to look for all instances of the GUID in the registry. (I just remembered there might be a command line tool that would have made that easier. At the time, I just used regedit). I backed up the keys and then deleted them from the regsitry. I started Visual Studio a few more times and didn't experience the delay. I've included my backup of those keys in the zip folders "reg v9" and "reg v10". I have since reapplied the registry entries without the slowdown.

I did not confirm my effective permissions on the registry entries. I am local admin and didn't think to check.

Thanks,
Daniel Carey
Posted by Microsoft on 4/28/2010 at 11:27 AM
Hi WHawke

Sorry for the troubles you've been experiencing.

If I am reading your posts correctly, it seems you are no longer seeing this problem - is that correct?

I'm also interested to understand how you came up with the workaround you've posted?

In addition, can I ask if you have installed the Silverlight 4 Tools for Visual Studio 2010, and if so, what release you have installed?

Thanks
Mark Wilson-Thomas
Program Manager, WPF & Silverlight Designer Team, Visual Studio
Posted by Luiscencio on 4/28/2010 at 11:05 AM
just tryed your workaround to remove Krypton toolkit I tworks just by removing #3 (=3)

thanks it was frustrating.
Posted by Daniel Carey on 4/15/2010 at 10:47 AM
After reboot, couldn't reproduce behavior with the Silverlight scenario. I've posted a workaround but haven't determined if it will do more damage than good.
Posted by Daniel Carey on 4/15/2010 at 6:01 AM
I think I've isolated the problem. It is related to Silverlight 3. If I remove the Silverlight runtime, I don't have the delay. If I install Silverlight, I get the delay.

I get the delay with both the developer runtimes and the standard runtimes. The following runtimes cause the problem.
3.0.40818.0 , 3.0.40818.0_Developer
3.0.50106.0, 3.0.50106.0_Developer
Posted by Daniel Carey on 4/15/2010 at 5:48 AM
The delay is back. I'm going to grab more detail....
Posted by Daniel Carey on 4/15/2010 at 5:07 AM
I'm unable to reproduce after uninstalling older Infragistic controls and rebooting.

During the problem, I launched a second instance of Visual Studio 2010 and attached the debugger. When I hovered over the Toobox and experienced the wait, the output indidcated that several FileNotFoundExecptions. Sadly I didn't capture the loading list.

If I can reproduce, I will post here. Thanks for your time.
Posted by Microsoft on 4/14/2010 at 10:59 PM
Thanks for your feedback.

We are routing 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.
Sign in to post a workaround.
Posted by Alexander Vezenkov on 5/3/2012 at 8:00 AM
I've been able to reproduce the issue with Visual Studio SP1 and SL 5 Tools installed.
Hope this helps:

http://community.infragistics.com/blogs/alexander_vezenkov/archive/2012/05/02/toolbox-doubled-items-issue-caused-by-sl5-tools-and-ria-1-0-sp2.aspx
Posted by Dimitri Hudon-Kampouris on 3/21/2012 at 2:15 PM
On Win7 x64

How I fixed my Slow Startup

Close Visual Studio

Go to

%USERPROFILE%\AppData\Local\Microsoft\VisualStudio\10.0

Delete all .tbd files

Start Visual Studio. It should load "Loading toolbox content from package Microsoft.VisualStudio.IDE.Toolbox.ControlInstaller.ToolboxInstallerPackage
'{2C98B35-07DA-45F1-96A3-BE55D91C8D7A}" but much faster as it seems to initialize it's cache.

Close Visual Studio

With RegEdit :

Navigate to the following key:HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\10.0\Packages\{2c298b35-07da-45f1-96a3-be55d91c8d7a}\Toolbox

Update the value of the "Default Items" value making it 0

Setting it to 0 seems to stop Visual Studio from loading this toolbox over and over again.

Start Visual Studio.

Problem should be gone.


Posted by Jaans on 3/19/2012 at 10:33 PM
This workaround from Michael Crump worked for me.

http://michaelcrump.net/fixing-a-broken-toolbox-in-visual-studio-2010-sp1
Posted by Rob Ainscough on 3/14/2012 at 9:59 AM
FYI, that registry value causing this bug is static, not random ... it's the same for all of us that encountered this problem. However, I would NOT recommend you remove this registry entries as they are InprocServer32 entries for mscoree.dll ... this is a key .NET Framework file.

In my case, SL5 dev toolkit was the cause of this problem. I have yet to find a reliable work around other than wipe my entire system and re-isntall everything from scratch. I guess this is why many developers now work with VM images so they can quickly go back to another VM image prior to it getting corrupted by one of Microsoft's installs.

So as far as I know, the only "safe" work around that has worked for me has been "Wipe the PC clean" re-install the OS, updates, VS, yada yada yada ... OR, move to VM and work from images -- you get about a 10% performance hit but until Microsoft actually start testing stuff, we have little option, VM it is.
Posted by GearWorld on 3/12/2012 at 5:08 AM
Please don't give a workaround like that since this can break something. Specially when you have over 50 entries in Packages which VS 2010 gives Loading toolbox content from package with ramdom key so I assume it's impossible to remove all those packages without having a real problem afterward.
Posted by Daniel Carey on 4/15/2010 at 10:40 AM
Searched through registry looking for "2c298b35-07da-45f1-96a3-be55d91c8d7a". Backed up the registry key and deleted it.

Found the entries in the following locations:
1. [HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0_Config\Packages\{2c298b35-07da-45f1-96a3-be55d91c8d7a}]
2. [HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0Exp\Configuration\Packages\{2c298b35-07da-45f1-96a3-be55d91c8d7a}]
3. [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\10.0\Packages\{2c298b35-07da-45f1-96a3-be55d91c8d7a}]
4. [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\9.0\Packages\{2c298b35-07da-45f1-96a3-be55d91c8d7a}]
5. [HKEY_USERS\.DEFAULT\Software\Microsoft\VisualStudio\10.0_Config\Packages\{2c298b35-07da-45f1-96a3-be55d91c8d7a}]
6. [HKEY_USERS\S-1-5-21-2705550674-1607040020-2235880358-1109\Software\Microsoft\VisualStudio\10.0_Config\Packages\{2c298b35-07da-45f1-96a3-be55d91c8d7a}]

Don't really know what I just broke but VS starts faster :-)