I just installed Visual Studio 2015 Community on my computer. Until now I have been using Visual Studio 2010 Professional. Now when I try to run my MVC apps in the build in web server, I get the following error message.
The procedure entry point __CrtGetFileInformationByHandleEx could not be located in \WINDOWS\SYSTEM32\msvcp120_clr0400.dll
I get the same error message if I try to execute vbc.exe (the Visual Basic compiler) on directly at the command prompt. My MVC app also shows a YSOD with
Compilation Error - Compiler Error Message: The compiler failed with error code -1073741511.
How can I fix my VS so I can run my programs again?!
Steps I've tried
Uninstall VS 2015 Community
Uninstall and reinstall .NET 4.6 and .NET 4.5.2
DISM /Online /Cleanup-Image /RestoreHealth
The .NET Repair Tool
Run sfc /scannow
Manually rename the msvcr120_clr0400.dll file to msvcr120_clr0400.dll.corrupt and do 1-5
Uninstall and reinstall VS 2010 w/ SP1
sfc /scannow successfully replaced the msvcr120_clr0400.dll file, but it replaced it with the exact same CTP file as before!
EDIT:
The problem dll's from my system are available for download here:
32 bit
64 bit
32 bit msvcr
64 bit msvcr
Microsoft is aware of this issue with KB3098779 and 3097997:
https://support.microsoft.com/en-us/kb/3118750
The recommendation is to uninstall these patches and then rescan for updates. Newer versions of these security patches (that do not break the VB compiler) are now available.
Okay, I see it from the files you uploaded to the sharing service, your .NET install is corrupted. A standard DLL Hell problem, your c:\windows\syswow64\msvcr120_clr400.dll file is the wrong version. Something you can see when you use Explorer and navigate to the file. Right-click and select Properties, look at the Details tab.
Note the word "CTP" in the Product name, means "Community Technology Preview". A Microsoft term that means "beta version". Clearly you should not be having the VS2013 beta on your machine. Your msvcp120_clr0400.dll is correct, it is file version 12.0.52512.0. It depends on an exported function in the msvcr DLL that the CTP version did not yet have.
Exactly how this happened is always hard to reverse-engineer. You are the 3rd SO user that I know of that had this problem this week, a bit too much of a coincidence. Two basic scenarios, if you ever had the VS2013 CTP edition installed on the machine then the problem is that it didn't get updated like it should have. Otherwise a very typical problem with CTP editions, they are pretty dangerous because the uninstaller is always the last thing Microsoft gets right. And the problem was just never detected until you started using a program that required this export.
Or it was caused by a rogue installer, copying the old version onto your machine without checking the version number. Much less likely, installers never have a good reason to install this particular file since it is only ever used by the .NET Framework. My money is therefore on your machine getting corrupted by the CTP.
You need to solve this by getting your machine fixed. Not that easy, you can never be sure how many other bad DLLs are lying around from such a bad CTP uninstall. A shortcut is copying this particular DLL from a good machine. But best to get .NET 4.6 re-installed.
EDIT from OP:
This answer correctly identified the problem files but reinstalling (or any other common steps) didn't solve it. In the end I copied "good" files from another computer with the version number 12.0.20806.33440.
KB3098779 appears to be the culprit on our server. That is the patch that installed the rogue CTP msvcr120_clr0400.dll mentioned in the above answer.
Solution: we reversed out the patch set that applied KB3098779, and everything is working again.
FYI: this is a .NET framework 4+ issue, not Visual Studio. Our server is a standard 2012 IIS server: Visual Studio is not installed.
I had the same issue on Windows 8.1 although KB3098779 and 3097997 were not installed on my machine. Probably it happened after installation of ASP.Net 5.
The issue was that I had both mcvcr files in version 12.0.51670.34230 while mcvcp files were already in 12.00.52512.0. It was enough to copy both mcvcr files (from System32 and SysWOW64) in this version from my colleague's pc.
If you have problems with permissions set to TrustedInstaller on these file, you can run this powershell command and then change permissions as Administrator:
takeown /A /F C:\windows\syswow64\msvcr120_clr0400.dll
Microsoft have issued a notice on this.
https://support.microsoft.com/en-us/kb/3118750
As others have pointed out too many people in too short a time to be a coincidence. Not a VS issue, this is to do with a bad update from Microsoft.
The info from MS mentions two security patches (KB3098779 and KB3097997).
I have uninstalled only KB3098779 and my site is up was up and running. It required a machine restart to complete
KB3097997 uninstalled without a restart. I maybe didn't need to uninstall but seems sensible given it is also subject to the same notice from MS.
Related
I'm currently trying to debug a weird issue I'm having with some RESTful API calls. I built an Angular 2 scaffold and used the publish feature to create a standalone build which users can run by opening a command prompt and typing in "project --debug" -> this will start the scaffold service and users can submit API calls to retrieve data from files. This works perfectly fine on my machine and I can make the API calls just fine, but I have another computer where the results are different. The other computer always fails and lands in an Exception block when accessing a specific type of file.
I'm wondering if this may have to do with some kind of version mismatch/difference on the .NET Frameworks and/or Microsoft Visual C++ redistributables. The published build (original computer) was built using .NET 4.5.1 while the other computer only has 4.6.1 installed.
Has anyone encountered a similar situation where the exact same build yields different results? I'm currently uninstalling versions of .NET and redistributables to test this hunch out but I'm curious if some of you may have had a similar experience.
Seems like my issue is related to the Microsoft Visual C++ 2015 Redistributables - I removed the 2015 redistributables from the original machine (because it turns on the other machine did not have them), and I received the same results. Going deeper, I'm guessing this is because one of the DLLs was built using the 2015 redistributables.
I have a C# application running on the .NET Framework 4.5 deployed via Microsoft ClickOnce. I also am utilizing a small utility from a Microsoft SDK called DComPerm.exe which is a C++ application that I had to compile separately. My main application uses Process.Start() to access this executable.
When I first tried running this on a client machine, I got an error message stating that VCRUNTIME140.dll was missing when the application tried to call DComPerm.exe.
This makes sense... since that program was compiled in C++ it needs the Visual C++ 2015 Redistributable package, which had not been installed on the client machine. I want to make this as painless as possible, so I was hoping I could bundle the VC++ 2015 Redist with my ClickOnce application. Under the project properties > Publish tab, there's a button for Prerequisites, which allows me to specify that the application should bundle the redistributable package.
That sounds great in theory, but it doesn't work. Now when I try to install my ClickOnce application on the client machine, it doesn't work. The installation fails and points me to a log file, which contains the following relevant information:
'Visual C++ "14" Runtime Libraries (x86)' RunCheck result: Install Needed
Installation of components 'Visual C++ "14" Runtime Libraries (x86)' was accepted.
Copying files to temporary directory "C:\Users\Owner\AppData\Local\Temp\VSD3872.tmp\"
Downloading files to "C:\Users\Owner\AppData\Local\Temp\VSD3872.tmp\"
(8/4/2016 12:57:48 PM) Downloading 'vcredist_x86\vcredist_x86.exe' from 'http://go.microsoft.com/fwlink/?LinkID=800028&clcid=0x409' to 'C:\Users\Owner\AppData\Local\Temp\VSD3872.tmp\'
Download completed at 8/4/2016 12:57:49 PM
Downloading failed with HRESULT=-2146697208
And that message makes it pretty clear what the problem is: the link that it's trying to use to download the redist package is dead. Only... I'm not sure how I can tell it to find the correct link. I'm quite surprised that it can't find it automagically as that seems like a bug with Visual Studio. Some searching revealed that the correct link is actually this one, but that's not what ClickOnce is resolving. I also saw that by checking the box this was the corresponding XML update to my csproj file:
<BootstrapperPackage Include="Microsoft.Visual.C++.14.0.x86">
<Visible>False</Visible>
<ProductName>Visual C++ "14" Runtime Libraries %28x86%29</ProductName>
<Install>true</Install>
</BootstrapperPackage>
Is there some XML tag I can use to specify the location explicitly? Or how else can I fix this? How can I bundle the redistributable without breaking my application?
I had pretty much the exact same problem. You asked how to specify the download location that ClickOnce resolves. In order to do that, open
C:\Program Files (x86)\Microsoft Visual Studio 14.0\SDK\Bootstrapper\Packages\vcredist_x86\en\package.xml
and edit the attribute with Name="https://go.microsoft.com/fwlink/..." to the correct URL. By the way, thanks for finding the correct download link, I hadn't been able to find it until seeing this post.
The VC++ Redis installed correctly on the client's computer after doing this.
I have devoloped a C# Application to search a certain directory, read in any files containing a certain string, and then compare those to a database and do various things with said information. I need to upload the project\exectuable to another machine where it will contantly run on a timer, however Every time I try to open the exectuable on any other device I get the windows error, the GradeUpdate (my project name) has stopped working. I created the project in Visual Studio 2013, and only have a few references out of the ordinary which are as follow, and I made sure these references are in my release folder that I copy over to the device which I need the program to run on.
MySqlData.dll
MySqlWeb.dll
I recreated the project from scratch thinking it may be a naming issue, but this did not make a difference. In addition a C# application written in Studio 2010 works on the machine that I am trying to access, however the 2013 application I wrote does not. I believe there may be some local file not included in the project folder that it access's on my local computer, but that is my best guess, any and all suggestions would be very welcome!
Could it be that the machine doesn't have the version of the .NET runtime you're targeting? If you're using Visual Studio 2013, your app may be targeting .NET 4.5. Can you make sure the target machine has the .NET 4.5 runtime installed?
the infamous works on the machine this is a common mistake that beginners make when learning to code.. just because it works on your machine will not guarantee that it will work on others I would first look at the properties of the .dll / assemblies and make sure that you have the CopyLocal property for the dll's set to true make sure that not only are you adding the assemblies in the using header section, but manually adding them to the reference node.. also make sure that the target machine has the same .net framework installed on their machine.
I come to you because I'm desperate. I've developed a GTK# application in C# with the latest MonoDevelop. It's built for .NET framework 4.0 / x86, and the only external library it uses is the official Mysql .Net connector. It's meant to run under Windows XP.
It's the first application I make with this IDE. I was very happy with the results and the development time, but the deployment is a real headache.
It works perfectly on the development machine. The debug is clean. Everything's okay.
Then, as I couldn't find any information about the deployment, I installed a clean XP to try it and see what do I should install on the client's machine.
I've installed the SP3, .NET 4.0 and copied the release package with all the DLLs mentioned in the build log (that made it work outside the MonoDevelop in the development machine). But I'm getting a "the application has encountered a problem and needs to close" error, with no exception, in kernel32.dll, offset 0012aeb.
I've tried to install the .NET 3.5 before the 4.0, updated IE (just in case...), copied more GTK# and Monodevelop DLLs to the exe's folder, installed the Mysql .NET connector, installed Mono 2.8... But nothing. Still getting that unexplained error.
Google and StackOverflow searches didn't help me. I've researched and tried a lot of things in the last twelve hours or more without moving from this machine.
Do you have any advice? What can be causing it? Is there any way to debug the exe (without installing VS...)? Does anyone know what are all the dependencies of this kind of executable?
WinDbg can help you figuring some JIT trouble...
Even though it aint intuitive and require skills, Worth a try. might pop something up.
If it's meant to run under Windows, then you should probably compile it with the Visual C# compiler.
However, more related to your problem - get a debugger in your deployment machine and run the application on it. This is the best way to figure out the problem because we really can't guess it.
Mono Application Deployment Guidelines
There are several options to installing Visual Studio on your production machine, one of them is the Remote Debugging Monitor. It does not require a Visual Studio installation. You can copy the files from your development machine to your server. I've got them under C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger.
You can also use it for Remote Debugging of a Project Built Locally.
In the course of some troubleshooting last week I uninstalled .net 3.5 thinking I could re-install, and did so (tried atleast), but now i can't seem to build anything targeted towards 3.5, I try to reinstall 3.5 but it keeps telling me i have to do it in windows features, so I've tried checking and un-checking that. Any help would be great.
Edit: I should probably add that I used revo uninstaller and completely blew away 3.5.
You have broken the .NET Framework. Congrats been there this is no fun. If you have Googled you surely have found
http://blogs.msdn.com/b/astebner/archive/2007/03/26/how-to-repair-the-net-framework-2-0-and-3-0-on-windows-vista.aspx
There it is mentioned that the .Net Framework on Vista+ is part of the OS you you cannot reinstall it as usual. The mentioned trick to call
sfc.exe /scannow
does not help since it does only repair missing files in locations under MSI and Trusted Installer control.
After searching a lot on my file system I did finally find my assemblies in an unexpected place. They are all installed a second time into C:\Windows\WinSxS... which is normally only used for unmanaged side by side dlls like the C-Runtimes or any other dll. I do not know how they did install it but normal MSI installations which do install into the GAC do not install the managed assemblies a second time into the WinSxS folder.
On a second thought it sounds reasonable since MSI and the installers do only care about files in the WinSxS system32 and other specially protected folders. The GAC is not protected in this way which means that the usual repair mechanisms do not work.
My way out of this mess was to use gacutil to simply install everything into the GAC again which is intallable from the WinSxS assemblies. With the following commands I had success:
1. C:\Windows\winsxs>for /D %i in (*_System.*) do for %j in (%i\*.dll)
do echo %~fj >> %TEMP%\assemblies.txt
2. C:\Windows\winsxs>for /D %i in (*_microsoft.*) do for %j in (%i\*.dll) do echo %~fj >> %TEMP%\assemblies.txt
3. for /F %i in (%TEMP%\assemblies.txt) do gacutil /i %i
I have nowhere found any explanation why the .NET assemblies are installed a second time in the WinSxS folder. MSI does treat managed and unmanaged assemblies nearly the same way but with the normal installers I do not get this behaviour. I do know that MS uses for Windows Components a technology similar to MSI but the underlying engine is quite different.
When you get OS patches they look like regular msi files but they aren´t. If you try to repackage them you will find out that the installation does no longer work. It would be very interesting to get more infos on this dark subject.
I ended up getting my machine re-imaged, as I think when I uninstalled .net 3.5 with revo uninstaller and completely blew away the reg and existing, I put my laptop in a very hard to repair state. I've given up and gone the re-image route, as according this article, this seems to be the best way to fix the registry.
http://blogs.msdn.com/b/astebner/archive/2007/03/26/how-to-repair-the-net-framework-2-0-and-3-0-on-windows-vista.aspx