I have just released a new build of our Command Ops engine, which involved a conversion here from VS2010 to VS2013. I have included the retail vcredist_x86 package and it all seems to work fine for most of our users. However, I have two users running i3 systems - one Win7 Pro and the other Win7 Home Premium. They both report the same issue in that the game app won't launch - in terms that nothing is displayed on the screen. The game app is not listed in the App listing of Task Manager but there is an entry for it in the Processor listing. After 20 seconds another two entries appear in the Processor listing. One of these can be closed down but the other two refuse and can only be got rid of by rebooting. They can launch one of our visual basic apps that come with the install package but none of the visual c++ apps.
My gut feeling is that there is some difference with one or more of the redistributable dlls. Hence my question about whether there are any known differences based on an i3 system. Any advice would be welcome. Thanks.
Related
Environment
I'm using Visual Studio 2019 version 16.7.2 on a Windows 10 VM, hosted by Parallels on a brand new MacBook Pro. The VM has eight virtual processors and sixteen gigs of RAM.
Nothing other than Visual Studio is installed on the VM.
What I'm trying to do
I'm trying to compile a Visual Studio solution consisting of seventeen projects. The projects are relatively small. They're all C# console applications or DLL libraries targeting .NET Core 3.1.
Problem
Typically a Rebuild Solution executed after a Clean Solution takes place in about ten seconds. A typical Build Solution (Ctl-Shft-B) that I execute throughout the day takes place almost instantaneously.
But occasionally, in maybe one build out of five, building the solution/projects causes VBCSCompiler.exe to consume 99% CPU usage and freeze up for approximately thirty to forty-five seconds prior to executing the build. Once it starts executing the build though, everything completes normally. This long delay which occurs time and time again is making my development cycle terribly frustrating. I'd like to find a way to eliminate this delay.
What's Changed
The build executed fine on my Amazon Web Server Windows 2016 m4.xlarge VM. I recently switched over to the Parallels VM to save money. That's when the problem began.
Again, I want to reiterate that the Parallels VM is clean. Nothing other than Visual Studio is installed there.
What I've Tried
The following tactics were applied to no avail.
(1) I turned off the Defender real-time virus checker.
(2) Based on the information in this post, I went to Tools | Options | Nuget Package Manager | General, and unchecked 'Allow Nuget to download missing packages' and 'Automatically check for missing packages'
(3) In Tools | Options | Projects and Solutions | Build and Run, I set the maximum number of parallel projects builds to one.
(4) Based on an answer to an unrelated question, I learned that I can view more information about the build process by setting 'MS Build project build output verbosity' to Detailed. I did so. I waited for the freeze to occur so I could examine the last line of output prior to the freeze. It reads as follows:
Using shared compilation with compiler from directory: C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Roslyn
This line always appears immediately before a freeze.
(5) Based on the output above, I Googled 'shared compilation' and discovered this post.
As a hobbyist programmer, the discussion that took place there, as well as the link in the accepted answer is well above my pay grade. It's unintelligible to me. If the answer lives in that post, I can't decipher it.
Any ideas on how to solve this intermittent freeze? If I can't figure it out, I'll have to assume it's something about my Parallels Windows 10 VM that's causing the problem, and revert back to developing on an Amazon server. I'd prefer to avoid that if possible because of the added expense.
Thanks for your consideration.
Best,
Festus
I'm working in a project building an application with Computer Vision using C++, OpenCV and Visual Studio. I'm no expert in deploying programs to use them on other PCs.
I've made a program which I need to distribute to a certain amount of people and I can't make it work on all the computers I'd like to. The program was written using Visual Studio 2015, it's an MFC Project and the code is written in C++ since I'm using OpenCV.
When it was finished, I tried to run it on another computer and I realized that it won't open. I looked on the Internet and found out that I needed to statically link the libraries, so I did it. Also, when I was looking for information, I found that Visual Studio 2015 builds its projects so you can run the programs on machines with Win7 to Win10. When I learnt that, I tried to open it on PCs running Windows 7, 8, 8.1 and 10. I tested my program in like 20 computers, give or take.
The results? I couldn't make it work for Windows 7, the error ucrtbase.terminate api-ms-win-crt-runtime-l1-1-0.dll showed every time I tried to open it. It also didn't open in one machine with Windows 8 without showing any error message, but it DID open on most of the machines with Win 8.1 and Win 10. The thing is that "most"; there were some PCs (with Win 8.1 and 10) that I couldn't open my program on. I found that sometimes it would show up in the Task Manager for less than a second and then disappear. The most stressful thing is that it doesn't tell me what the problem is, it doesn't show any error message. It just won't open.
I tried using Dependency Walker (both on my PC and one of those that I couldn't run my program on) to see if there's something missing and I got a reeaaally long list of files that the system couldn't find, here's an example:
List 1/11. Something curious is that my program executes just well on my computer and on those I could open it, even though Dependency Walker (DW) tells me that there might be a problem with it. This indicates me that DW is not finding the exact error I'm having.
Another thing I've tried is to compare the things I have installed on my computer and install them on the one I want to execute my program on. I tried installing .NET Framework 4.6.1 just because VS 2015 says that my project was built using it (and I have it installed in my PC and that other one doesn't. Also I tried with .NET 4.6.1 SDK). Nothing changed.
Just look here:
https://msdn.microsoft.com/de-de/library/ms235299.aspx
The quick-and-dirty way would be to copy the DLLs from your redist directory. For my MS VS 2013 it is hidden under the VS installation directory in:
VC\redist\x86
or
VC\redist\x64
...
which depends on your application.
I made a program in Microsoft Visual Studio C++ and used the SFML for this. I included the correct .dll-Files, that the program needed, and copied them into the "Release"-Folder. It worked. The entire program worked flawless on my computer, but as soon as I tried to run it on another computer, it said: Missing "MSVCP140.dll" and Missing "VCRUNTIME140.dll.
I searched for a solution of this program, and always heared "Go to Project > Project Settings > C/C++ > Code generation > Runtime libraries > switch to Multi-Threaded (/MT). I compiled the project with this settings, and the executable increased in size, which they said is normal, because there are no supporting .dll-Files anymore.
But as I tried it again, with the new .exe, it gave me the exact same Error-Messages. Are there any other possibilities to solve this WITHOUT installing some -dll-Files onto the computer?
This is covered on MSDN in some detail. See Deployment in Visual C++
You really have three choices:
Use the "centralized" versions of the DLLs. For this you should have a setup program that runs the VCREDIST_*.EXE packages for VS 2015 or if using a MSI-based setup you can use the MSM files provided.
Copy the required DLLs as part of your program. This means your installer or zip file or whatever that has the EXE includes the DLLs it needs too. This is the best choice if you want "copy and run" style deployment, but remember that all security servicing of the DLL is now your problem.
Use static linking. From a security perspective this is the least desired solution, and really should only be used in the specific cases of writing an installer--i.e. the program that installs an app has to run in the first place.
You have not specified which version of Windows is running on your target machine. VS 2015 does not support Windows 7 RTM as it's out of support, but it does support Windows 7 Service Pack 1 along with Windows Vista Service Pack 2, Windows 8.x, and Windows 10.
While we are on the subject note that Windows 8.0 is also out of support. Those users need to upgrade to Windows 8.1 Update or Windows 10.
I'm working on an AIR app that uses a Native Extension for windows that I developed for the same project. The app calls an ANE method called pingFunction and passes it a String containing the IP address where the pingFunction will perform, believe it or not, a ping test.
The application and it's ANE work great on Flash Builder and even after making it a release, they keep working like a charm on the development PC. The problem is that I've tried on two other computers and the application is throwing the following error:
ArgumentError: Error #3500: The extension context does not have a method with the name pingFunction.
at flash.external::ExtensionContext/_call()
at flash.external::ExtensionContext/call()
at com.mycompanyname.myappname::MyAppName/sendPing()[...
At the beggining I thought I had to do with the fact that I was using a DLL I compiled using the Debug configuration on Visual Studio instead of the Release configuration, because I read that sometimes the a debug-version of a DLL can use external DLLs. So, I changed it and rebuilt the whole library as a release build. Sadly for me, I'm still experiencing the same result.
Also, I tried changing the swf-version of both the AIR app and the ANE to the AIR SDK version I'm using (14.0), and got again the same error.
The development computer is running Windows 8.1 and the others, where the app is not working, Windows 7 and Windows 7 Service Pack 1.
Any ideas about why this is happening? Any questions or comments that might lead me to the right track will be deeply appreciated.
Error#3500 is coming because you don't have the required runtime installed on those machines, which is necessary to execute any c++ code .
On your development machine you have visual studio installed and hence you also have msvcr.
Solution of the problem is:
Install msvcr i.e. Microsoft Visual c++ redistribution - 2012 from here.
you need msvcr anywhere you want to run any VS compiled c++ code.
I've written a C++ console application in Visual Studio 2019 and am trying to deploy it to another windows laptop. Both laptops are up-to-date with 64 bit Windows 10, and my target laptop has installed/up-to-date .NET Framework, vc_redist.x64.exe, and DirectX.
In terms of deployment method, I followed this Microsoft walkthrough word for word, with the added step of ensuring that my newly created "setup" project was also targeting x64 platform, since some of the external libraries in my code required x64. The resulting "setup" .exe/.msi pair work as planned on the source laptop - installs and runs with no frills required.
Installation goes fine on the target laptop, but launching the program gives the error mentioned in the title of this post. After a few hours of trying to figure it out, I think I have an idea where the problem is coming from, but first, I'll share what I've tried, which is basically every recommendation found by googling this error code:
clean boot
SFC scan
chkdsk c: /f /r
repairing/fresh installing all of the frameworks mentioned in the first paragraph
running both the application installer and the installed application as administrator
restarting laptop and reinstalling application after all of those changes
What I think is the root of the problem:
In the setup/deployment project in VS, three of the "detected dependencies" (MSVCP140D.dll, ucrtbased.dll, VCRUNTIME140D.dll) have filepaths through …\System32\ rather than the identical dependencies that could be found in …\SysWOW64. The other two detected dependencies are external 64-bit DLLs (which is why I specified my entire project to x64). When I run my application through Dependency Walker, it agrees that the three formerly mentioned dependencies are "wrong CPU type", while the two latter ones are fine. This scenario does not, however, explain to me why install/run (outside of VS) works fine on the source laptop (shouldn't it not work if VS is packaging a mix of 32 and 64 bit dependencies?). In fact, running the application through Dependency Walker on the source laptop reveals the exact same thing as on the target laptop - the same 3 dependencies are "wrong CPU type", yet the application runs here.
I do not see an option in VS to change the "setup" project to read the 64 bit filepath. I have tried manually swapping in the 64-bit DLLs at various stages (including restarting the computer between DLL swap and application run), which did not seem to have any effect. In fact, I tried replacing the 3 relevant DLLs in the System32 folder with the DLLs from the SysWOW64 folder (my idea of a cheap workaround for not being able to change the filepath - just change the file) and this just caused me to get the same error on my source laptop as I had been getting on my target laptop.
All of this stuff is relatively new to me, so please let me know if I'm foolishly overlooking some fundamental detail with my process/project - at this point it would be nice if that were the case and this is easy to fix.
Wrote this before I noticed the above comment had already answered.
Just leaving it in.
Debug Binary: Looks like you have deployed a debug version of your binary (The D in the file name: MSVCP140D.dll). Try to compile in Release mode and deploy the new binary.
Cause: Debug binaries generally need the debug-versions of the VCRedist binaries to exist on the box you try to run the binary - they are only available on developer PCs with the SDK (and / or Visual Studio) installed. That error message: 0xc000007b means "STATUS_INVALID_IMAGE_FORMAT".
Tips: There are some resource links here and some tips on how to debug deployment problems.