Receiving: Exception has been thrown by the target of an invocation - by Martin Moe

Status : 

 


7
0
Sign in
to vote
ID 501190 Comments
Status Active Workarounds
Type Bug Repros 7
Opened 10/24/2009 3:34:52 AM
Access Restriction Public

Description

We have a product that probably is in the upper range of the complexity and size scale (160+ .NET projects/assemblies).

After installing VS2020 B2 I test ran our build using MSBuild 4.0. Almost everything compiled and I was extremely encouraged (;)). Then I opened a solution I have prepared containing almost all of our projects to see whether VS2010 could cope with the conversion job.

During the first run it came almost halfway through the conversion before bailing out with an OutOfMemoryException. On the second and third tries it seemed to med that it got further and further so I figured it would get though the conversion eventually.

This did not happen. On the fourth try, during startup, VS presenting me with an error box saying "Exception has been thrown by the target of an invocation" and failed to lauch. It kept doing this so I figured it's already time for my first repair. After running the reapir option of the setup VS still failed to launch with the same error message popping up. I even tried uninstalling and reinstalling, same story. So now I am stuck and my VS2010 Beta 2 testing days are over even before they begun, unless I nuke my laptop of course, which I am not going to do.

I am not whether this has anything to do with the main problem, but during the first install there was a hickup because I had, stupidly enough, mounted the ISO from a network share and forgot to set PowerIso to automount, so after the reboot of the install the installer threw me a 'Cannot find file, Retry?Cancel?' at which point I simply mounted the ISO again and selected 'Retry'. The install seemed to recover nicely, but still reported this as an error in the install log apresented afterwards.

On the later repairs/uninstalls/installs I had the ISO located on local disk with automount set for PowerIso and then of course the setup was not interrupted by this.

Also worth mentioning that I discovered the 'Install Documentaion' button on, I think, the third go and tried to click that (one wants docu). This hovewer failed, and I found this entry in the event log that might shed some light on this particular problem:

An unexpected error occurred on startup: System.TypeInitializationException: The type initializer for 'System.Windows.Window' threw an exception. ---> System.TypeInitializationException: The type initializer for 'System.Windows.FrameworkElement' threw an exception. ---> System.TypeInitializationException: The type initializer for 'System.Windows.Documents.TextElement' threw an exception. ---> System.TypeInitializationException: The type initializer for 'MS.Internal.FontCache.Util' threw an exception. ---> System.UriFormatException: Invalid URI: The format of the URI could not be determined.
   at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)
   at System.Uri..ctor(String uriString, UriKind uriKind)
   at MS.Internal.FontCache.Util..cctor()
   --- End of inner exception stack trace ---
   at MS.Internal.FontCache.Util.get_Dpi()
   at System.Windows.SystemFonts.ConvertFontHeight(Int32 height)
   at System.Windows.Documents.TextElement..cctor()
   --- End of inner exception stack trace ---
   at System.Windows.FrameworkElement..cctor()
   --- End of inner exception stack trace ---
   at System.Windows.Window..cctor()
   --- End of inner exception stack trace ---
   at System.Windows.Window..ctor()
   at Microsoft.Help.Manager.ContentLocationPicker..ctor()
   at Microsoft.Help.Manager.WindowFactory.ShowModalContentLocationPicker()
   at Microsoft.Help.Manager.AppLifecycle.Start(CommandLineParser parsedArgs)
   at Microsoft.Help.Manager.App.OnStartup(StartupEventArgs e).

What's more important is that I have a large number of events following this pattern (different assemblies that fails to compile):

.NET Runtime Optimization Service (clr_optimization_v4.0.21006_32) - 1>Failed to compile: C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies\Microsoft.Windows.Design.Platform.Silverlight.dll . Error code = 0x80070002 

On demand I will upload them all.

Sign in to post a comment.
Posted by Microsoft on 6/13/2012 at 10:31 PM
The WPF team has recently reviewed this issue and will not be addressing this issue as at this time the team is focusing on the bugs impacting the highest number of WPF developers. If you believe that this was resolved in error, please reactivate this bug with any necessary supporting details.
Posted by v-mohdkh on 7/30/2010 at 10:04 AM
Posted by BrianLow22 on 7/28/2010 at 3:07 PM
- delete any fonts you cannot preview in c:\windows\fonts
     http://social.msdn.microsoft.com/Forums/en-US/windowsgeneraldevelopmentissues/thread/eb2f909a-5f4b-4f7a-ac48-244ee1c40d1f
    - delete any invalid font registry entries
     http://alissonsol.blogspot.com/2009/02/when-wpf-applications-dont-start.html
    - clear the font cache
     http://support.microsoft.com/kb/937135/en-us
    - verify windir and systemroom environment variables are correct
     http://social.msdn.microsoft.com/forums/en-US/wpf/thread/ad43102f-6f66-4c43-a3f9-9f68783385fa
     https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=522003&wa=wsignin1.0
    - verify path environment variable not too long
     http://connect.microsoft.com/VisualStudio/feedback/details/501190/receiving-exception-has-been-thrown-by-the-target-of-an-invocation
Posted by RicarDog on 7/25/2010 at 12:47 PM
I had the same problem here on Windows 7, my system %PATH% had 2137 characters long, and the system stopped working properly - icons not loading, control panel links throwing error messages and VS2010 with the same issue as described here. Seems like a Windows issue.
Posted by Chipalo [MSFT] on 1/27/2010 at 12:07 PM
Very interesting. Thanks for letting us know about that one.
Posted by Martin Moe on 1/26/2010 at 6:24 AM
Update:

I just discovered that my System PATH variable had overrun the size thresholds. For some odd reasons there were several duplicates of many of the entries. Ones I cleared out the duplicates and restarted the box VS2010 started just fine. Furthermore the tests on %windir% works as expected.


Thx for the help

Martin Moe
Posted by Martin Moe on 1/22/2010 at 12:39 AM
Ok. So I just did a trick to confirm this as the root cause and figured out a workaround simultaneously.

Using ProcExp I killed Windows Explorer. From a command prompt I set windir to c:\Windows, then started Explorer from that command prompt. The new Explorer process now has windir set correctly, and what's more, I can start VS2010 just fine from here :-)

I can live with this until I get W7 on my laptop (I have another machine for my main dev work anyway). If you find the cure for the underlying decease though, I would very much like to hear it.


Martin Moe
Posted by Martin Moe on 1/22/2010 at 12:27 AM
Hi Chipalo ;)

%SystemRoot% resolves just fine to c:\Windows and I am running Vista SP2. As you can see from my previous post I was thinking along the lines of this being an access right problem (since it looked like only processes run under my account had this problem). Just checked it a bit more this morning and I found the black seagull (thus proving the existence of such creatures). the Desktop Windows Manager has %windir% set properly.

My next hypothesis is that all processes spawned from Windows Explorer suffers from this (including of course explorer itself). This hypothesis seems to fit the observations better.

Does this raise any triggers in you? Anything I can test for? Experiment with? IT-management is still in the planning stages of rolling out W7 here, so I will not be able to switch OS for a while yet :-|. Reinstalling Vista is of course an option, but a bad one right now.

Martin Moe
Posted by Chipalo [MSFT] on 1/21/2010 at 2:44 PM
Hi Martin, the past couple messages have been from Chipalo. I am a PM on WPF. We have seen similar errors caused by strange registry settings. Your case looks related, but is actually different than the issue we have seen previously.
In the past, some users’ %windir% environment variable does not resolve properly, and the same holds true for you. This has been caused by the windir reg key type being set to REG_SZ as opposed to REG_EXPAND_SZ. What’s interesting is that your windir reg key is set properly. I’ll forward this problem around our team to see if we can get you an answer. In the mean time, please let us know what echoing %SystemRoot% gives you. Also, what OS are you running?

Chipalo
Posted by Martin Moe on 1/21/2010 at 3:35 AM
Hi Sasha

Any news on this?

It seems to me that no processes in my security context(?) get this environment property set, but all system owned processes do. Known issue? I have tried to G***** this problem but can't find anything on it.

Martin Moe
Posted by Martin Moe on 1/20/2010 at 1:08 AM
Hi Sasha

C:\>echo %windir%
%windir%

So, nothing in that variable. Interesting!

windir under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment:

Type: REG_EXPAND_SZ
Value: %SystemRoot%


Martin Moe
Posted by Chipalo [MSFT] on 1/19/2010 at 1:32 PM
Hi Martin, please check the value of the WinDir environment variable on the machine which you are having problems (echo %WinDir%). Also could you please check the type of the "windir" registry key under
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
Posted by Martin Moe on 1/15/2010 at 3:01 AM
Hi Sasha

Looking forward to that. Just some extra info. I found this posting (http://social.msdn.microsoft.com/Forums/en-US/setupprerelease/thread/ef4990d4-3eba-4968-aff5-6857f4c62290) and tried the proposals there. Nothing worked, but it drew my attention to the VS2010 registry settings.

So, I am placing a bet here on the root cause being that I have moved my home directory to a network share (nice to have Documents access on all machines). This has caused me problems in the past with add-ins to older versions of Visual Studio. I seem to have suppressed my past experience on this, so I did it again.

Works fine right now for both VSS2005 and VS2008 though. Typically this lead to some security policy failure in the past (different time, different employer, different ACLs, different security policies)

Anyway, I have entries in HKCU\Software\Microsoft\VisualStudio\10.0 that are of the form H:\Documents\Visual Studio 2010\Projects. So I tried to change them to C:\Users\... It didn't help but VS managed to rewrite them back to H:\Documents\... before halting with the same error as before.

Just thought I would mention it ,)

Regards
Martin
Posted by Microsoft on 1/14/2010 at 1:00 PM
Hi Martin,

This appears to be be a known issue - I will follow up with the area owners and see if we can find a workaround to unblock you.

Thanks,
Sasha
Posted by Martin Moe on 1/14/2010 at 4:23 AM
Done

Martin Moe
Posted by Microsoft on 1/13/2010 at 3:38 PM
Hi Martin,

Unfortunately, looks like the file shares expired over the holidays - can you please upload your dumps again to:

https://sftus.one.microsoft.com/choosetransfer.aspx?key=a0655649-8545-431e-8fb0-4f043fa2376c

Password: %$ZPkmBX^U

I apologize for the inconvenience.

Thanks,
Sasha
Posted by Martin Moe on 1/12/2010 at 12:55 AM
Hi Sasha

As my previous post will show, yes.

Martin Moe
Software Architect
Confirmit ASA
Posted by Microsoft on 1/11/2010 at 2:45 PM
Hi Martin,

I am catching up on this bug - have you been able to grab dumps for the first chance exceptions encountered on startup per my instructions on 12/1?

Thanks,
Sasha
Posted by Martin Moe on 12/3/2009 at 2:26 AM
Hi Sasha

Yes I did try "devenv /resetuserdata". All it did was present me with the configure for this or that type of role before running that configuration and then back into the same error situation. So I guess you know something more then, that the error happens after the loading of the configuration, yes?

Created and uploaded a dump as prescribed using windbg.

Regards

Martin Moe
Software Architect
Confirmit ASA
Posted by Microsoft on 12/1/2009 at 2:00 PM
Hi Martin,

Unfortunately, there is not enough information in the dump to track down the root cause of the problem. Can you please do the following:

1) Install windbg (http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx)
2) Launch windbg and enable CLR exceptions by entering "sxe clr" into the command window
3) Launch VS under windbg. You will now break into the debugger when first chance exceptions are hit.
4) Grab a dump at the point of the first chance exception (".dump /ma").
5) Upload that dump.

Also, did you try the earlier suggestion to run "devenv /resetuserdata" to clean up your profile? That might unblock you in the meanwhile.

Thanks!
Sasha Siddhartha
Lead Software Developer
Visual Studio Platform
Posted by Microsoft on 12/1/2009 at 2:00 PM
Hi Martin,

Unfortunately, there is not enough information in the dump to track down the root cause of the problem. Can you please do the following:

1) Install windbg (http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx)
2) Launch windbg and enable CLR exceptions by entering "sxe clr" into the command window
3) Launch VS under windbg. You will now break into the debugger when first chance exceptions are hit.
4) Grab a dump at the point of the first chance exception (".dump /ma").
5) Upload that dump.

Also, did you try the earlier suggestion to run "devenv /resetuserdata" to clean up your profile? That might unblock you in the meanwhile.

Thanks!
Sasha Siddhartha
Lead Software Developer
Visual Studio Platform
Posted by Microsoft on 11/30/2009 at 9:14 AM
Hi Martin,

Just got back from vacation - I'll take a look at your dump file today.

Thanks!
Sasha Siddhartha
Lead Software Developer
Visual Studio Platform
Posted by Martin Moe on 11/30/2009 at 6:00 AM
What happens to this? Any progress?
Posted by Martin Moe on 11/12/2009 at 8:53 AM
Added MiniDump for the state when the messagebox appears while assuming this might be to late to pinpoint the actual error. Please advice as to further steps to provide more input. And please reactivate this issue. I would very much like to be able to test VS2010, .NET 4.0, MSBuild 4.0 etc. in our context.

Also attaching screenshot of the error message popup.
Posted by Martin Moe on 11/10/2009 at 6:54 AM
Aha! Currently have Chrome as my default browser (free choice isn't it?!) and it seems that the attachment form doesn't work in Chrome. Switched to IE and uploaded fine.

Who's to blame? I'm not about to flame.
Posted by Martin Moe on 11/10/2009 at 6:24 AM
This is the response after I choose Submit in the attach files form:

Feedback
attach files
You want to attach a file to this feedback item:

Title: Receiving: Exception has been thrown by the target of an invocation ID: 501190 Description:
Attach More Files
Back to Feedback Item
Posted by Martin Moe on 11/10/2009 at 6:21 AM
Hi

Sorry for the delayed response. I am a buzy man.

I tried to upload an attachment but just got a weird feedback from the upload form ("You want to upload ...") and no attachment was added. Any clues to what I am doing wrong?
Posted by Microsoft on 11/10/2009 at 1:17 AM
Hi, given that we have not heard back from you in 7 days. We will go ahead and close this Connect Issue. If you get a chance to review and provide the information requested earlier, you can go ahead and reactivate this issue.
Posted by Microsoft on 11/3/2009 at 2:48 AM
Thanks for reporting the issue.
In order to fix the issue, we must first reproduce the issue in our labs. We are unable to reproduce the issue with the steps you provided.

Could you please attach a callstack and a dump to help us investigate the issue? You can get detailed steps about how to get callstack and dump file at http://blogs.msdn.com/kirillosenkov/archive/2008/12/07/how-to-debug-crashes-and-hangs.aspx


Thanks again for your efforts and we look forward to hearing from you.
Visual Studio Product Team
Posted by MKPotluri on 10/27/2009 at 10:53 AM
Martin, exception above could not be the rootcause for VS (help in VS10 starts out of proc). Can you verify if your profile reset revives VS10 by running "devenv /resetuserdata" from Visual Studio 2010 command prompt?
Posted by Microsoft on 10/26/2009 at 4:44 AM
Thank you for your feedback, We are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)