3

I am getting the error message in the title on a VPS running Windows Server 2008 R2 Enterprise SP1 when I try to open Visual Studio 2010. Things were working fine in the beginning even after I installed SQL Server 2012 and VS 2013.

In trying to resolve this, I found others who had this issue stating that the 32 bit version of the msvcp100, msvcp100d, msvcr100, msvcr100d, and msvcr100_clr0400 DLLs in the SysWOW64 folder were overwritten somehow with the 64 bit version. So, I downloaded the 32 bit version and replaced them with no luck. I, also, removed the versions in the system32 folder. This didn't work either so I put the originals back.

I, also, performed a full clean uninstall of Visual Studio 2010, then, I reinstalled VS 2010 Shell Integrated; Visual Studio still will not start and gives the same error.

Can anyone help me to resolve this issue? If it is a problem with a DLL, does anyone know of a tool to help me narrow down exactly what DLL(s) are causing the problem?

Any help would be greatly appreciated. Thanks!!!

cnotes
  • 247
  • 1
  • 4
  • 15

4 Answers4

3

Using the Dependency Walker tool and finding a post that provided a little information on how to use the tool, I figured out that I had a 64-bit version of the ATL100.DLL instead of the 32-bit version. This file went missing earlier and I unknowingly downloaded and replaced it with a 64-bit version.

cnotes
  • 247
  • 1
  • 4
  • 15
  • I'm tired listen about "Dependency Walker" ... I use this program and this program says me : that I need "API-MS-WIN-CORE-KERNEL32-PRIVATE-L1-1-1.DLL" and I go to c:\windows\system32/syswow and exist. This solution not work for me –  Aug 30 '15 at 22:07
  • 1
    @delive just because Dependency Walker doesn't work for you and you don't know how to fix it, don't invalidate it and complain about correct answers sharing good information on how to fix issues. I've used dependency walker myself in the past and it's a very useful tool. – Josh Apr 13 '18 at 14:07
1

I've looked around for details on this issue, and haven't found anything conclusive. One post, from a Microsoft support technician, states this:

"From your error 0xc000007b I found that the error means this: "STATUS_INVALID_IMAGE_FORMAT" ".

The error message is probably referring to a file image - most likely one of the MS VS SDK DLL's. The exact file name should be in the Windows Event Logs - Application section. If not, they are probably in a log file (in your %temp% area).

Assuming you can't find the file name: Have you tried a repair of all the VS 2010 SDK's? If a file has been updated (via MS installer) since the install of MS VS, it will not be rolled back via install - even if it's invalid. It won't be removed if you uninstall, either, since another app installed/updated it. You need to force this via repair (in "Programs and Features)".

Update: MS Repair Tool for .NET Components - Not sure if it's just .NET libs or if it scans VC++/VC#/etc. I'm still searching for a similar tool for other MS components.

ALSO: If none of that helps, try the following:
-Force the error to occur, and leave the process running (VS 2010) with its error message
-Pull up Process Explorer (utility from Microsoft - sysinternals.com) and select that process
-Enable DLL view for the lower pane
-Look through the DLL's, and there should be one in there with an odd date, and perhaps in an odd location (like in the VS 2010 folder, and not System32.)
-Close VS 2010 (and its error message)
-Move any DLL's that don't live under system32/syswow64 to a temp location (don't forget where you got them!)
-Launch VS 2010 again

LATEST CONTENT:
Try this for better logging - launch VS2010 like this:
devenv.exe /Log

Log goes here:
%APPDATA%\Roaming\Microsoft\VisualStudio\\ActivityLog.xml

More devenv.exe switches in the [source web page]2.

shornby
  • 46
  • 4
  • Yes, I have done a repair of the VS 2010 installation. – cnotes Aug 31 '14 at 22:53
  • I have a listing from the Dependency Walker tool. Does anyone know how to read the listing? – cnotes Aug 31 '14 at 23:02
  • Also tried the MS Repair Tool you suggested with no luck. Thanks for the suggestion. – cnotes Aug 31 '14 at 23:12
  • I also tried the Process Explorer. About 21 DLLs showed in the lower window and nothing really looked suspicious except this locale.nls file in the System32 folder. Some of the DLLs displayed were 32-bit and some were 64-bit. Is that normal? I thought they should be one or the other. I was expecting 32-bit since VS 2010 is 32-bit (running out of "Program Files (x86)". Correct? – cnotes Aug 31 '14 at 23:32
  • Ok, I tried to post a reply, and NO formatting exists in the mini-Markdown. New line = wrap text. REALLY annoying. Anyway, check out my post. I think I have a solution. – shornby Sep 01 '14 at 00:00
  • I tried your latest suggestion but there wasn't an ActivityLog.xml file in the specified location. I think maybe because the error dialog pops up immediately upon starting VS, the log may not get created. I'll try it again and look at the link for devenv.exe switches....may find something that helps. Thanks! – cnotes Sep 01 '14 at 00:34
  • Check out the latest path in my article - I initially posted the location for the VS 2013 log file, assuming it was the same as VS2010. It's not! If that fails, just do a search in your profile for recent *.xml files. – shornby Sep 01 '14 at 01:41
  • Am I missing something here? Could you tell me what article you are referring to? – cnotes Sep 01 '14 at 01:55
  • The one in my post. Earlier today I mistakenly posted the VS2013 log file path, which is quite different from the VS2010 location (they switched from local roaming.) If you copied the link before I fixed it, you won't find anything. Make sure you check the link again, or just do a recursive search for a recent XML file. – shornby Sep 01 '14 at 04:42
  • Is this still an issue for you, or did the dependency walker tool take care of things? I can't tell because you haven't marked anything as "useful". No worries. I still can assist with a remote support tool if you want (like Chrome Remote Desktop or Webex.) Cheers, Steve – shornby Sep 02 '14 at 20:21
  • Yep, the Dependency Walker helped. I couldn't mark it because I had to wait 2 days before SO would let me. Thanks for your help. – cnotes Sep 02 '14 at 21:55
  • If my post helped you to find a solution, even indirectly, I would appreciate a "Useful" rating for my answer. I put a lot of work into it. – shornby Sep 06 '14 at 19:47
0

I solved this by changing the platform from properties >> configuration manager to win64, and change the Additional Library Directories to x64.

enter image description here

Fadwa
  • 1,717
  • 5
  • 26
  • 43
0

For me I got same issue, The problem was due to 32/64-bit mismatches of various system dlls required by Visual studio. Somehow the dlls it needs got replaced by 64-bit versions that it couldn’t load. I uninstalled x64 vc++2013 redistribute and installed x86 and it started working.

Anurag Daware
  • 441
  • 1
  • 5
  • 15