I have gone over every example I can and I can't seem to get this error to go away.
I have tried =
Setting build from x64 to x86 to AnyCPU = no work
I have tried deleting IIS Express folder = no work
I have tried deleting .vs project folder = no work
I have tried changing project config from override application root URL on/off = both no work
I have tried swapping from IIS Express in config to Local IIS = no work
I have tried changing IIS app pool to allow 32 bit = no work
I have only noticed one thing that I have no idea if is the issue:
picking the one assembly and checking its Version against the packages.congig file = they have different versions : could that be the issue?
What else can I do here?
Ok, tried one more thing and it worked = I had NuGet get the latest of the one library it was always erroring out on, and then the build worked again... I think my packages and build library got out of sync somehow. It works now though.
Related
I'm new to Qt, but have been working with Visual studio for C/C++ development for a few years. Now I'm trying to build a GUI for my project. I installed Qt 5.11.0 and the Qt VS Tools on both my work computer and home PC. At work I can build and run my project with the VS debugger, however on my home system I can build but can't run either with VS debugger or simply launching the app. I tried in release and it runs fine.
The error I'm getting is :
The code execution cannot proceed because VCRUNTIME140D_APP.dll was not found.
I get 4 of these, the first two want VCRUNTIME, the second two want MSVCP140D_APP.dll.
Solutions I've tried so far :
Uninstalled Win SDK and reinstalled
Uninstalled VS2017 and SDK and reinstalled
Searched System32, SysWOW64 and VS install directories - found msvcp140d.dll and vcruntime140d.dll, but no _app.dlls
Does anyone know what these are included with and where to get them? I can't figure out why I have them on my work computer but not at home. I have the same VS updates, same Qt version, and SDK on both systems.
Using :
Visual Studio 2017 v15.7.1
Qt 5.11.0 - msvc2017_64
I suppose I can just copy the .dll's from my work pc and drop them in the appropriate locations on the other, but I'd like to know what they should have been installed with so I can have the same setup on both systems.
Edit:
I also tried changing the platform toolset to VS2015 with Qt versions msvc2015_64 and winrt_x64_msvc2015
I found this post concerning the same missing _app.dll files. There wasn't any answer there, which is why I tried reinstalling the SDK in the hope the missing files were included there.
Edit 2:
I just scanned my entire system at work and it turns out that I don't have the missing .dll there either. That tells me that there is a difference in the project properties or configuration between the two. I use git for source control, and I am currently the only contributor to this project. When I try to build and run just the example from the getting started guide I have the same problem at home with missing _app.dll files, however it works fine at work. I'm totally confused now, and any hints are greatly appreciated.
Solution:
After trying for a couple of hours making new solutions etc. I decided to delete the entire build folder and put fresh copies of all the dependencies into it. My project now runs fine in debugging mode.
I'm fairly certain that when I originally copied the Qt .dll files into it I must have grabbed them from one of the winrt folders rather than the msvc2017_64 folder. To test I replaced the working .dll files with those from the winrt_x64_msvc2017 folder and sure enough the same errors again. So, this was a dumb mistake on my part, but hopefully it'll save someone else a lot of hair-pulling in the future.
I am using Visual Studio Community Edition 2017 and trying to create a UWP application.
I get the following error
Your project is not referencing the "UAP,Version=v10.0.10240" framework. Add a reference to "UAP,Version=v10.0.10240" in the "frameworks" section of your project.json, and then re-run NuGet restore.
I had the same issue on my build machine. What's weird is everything runs fine on my local machine.
I managed to fix this by going into the project properties for my UWP app, and changing the Target version to match the Min version.
The reason I believe this issue is happening is because when targeting a higher framework, on a Windows Server machine (the build agent) it doesn't restore all of the packages between your min and target version. It seems to build fine against the version you target.
By the way Ken, following the instructions given by the error don't fix the issue. Try not to be so rude. I came to this page looking for the same issue, and you are no help at all.
I have the same issue, after I remove my bin and obj folder, I can build mine and see the errors gone.
I recently ran across this same issue when updating the target framework. The issue turned out to be the Nuget Restore task in my VSTS Build definition needed to be updated to the latest version (2.*). Once I did that, the builds worked as expected.
I agree with Jeff. Ken Not sure if you should be giving any answers with this kind of attitude.
The error message is misleading there is not project.json at least you cannot see it in the Visual Studio explorer.
I had the same issue and have min and target version set to the same number but it would not build.
The fix was to make sure in Nuget package manager setting to tick checkbox 'Allow Nuget to download missing packages' and the one below it as well and rebuild the project.
This is a pretty weird mistake, but what worked for me :
1st Solution:
1 - Change your project target to "10.0.10586" (or up)
2 - Make a clean / nuget restore / rebuild
3 - Return the project target to the "10.0.10240"
4 - Make a clean / nuget restore / rebuild
Do not ask me why, but it worked :)
2nd Solution:
If you use a repository with Tortoise, try making a CLEANUP
I had an old Backup folder in my project that contained a project.json. Looks like it might have been from an earlier upgrade. I deleted Backup and got a good build.
This happens in exactly this manner, if projects were generated in the year 2017 in the phase where MS changed to project.json and then decided against it. I tried several solutions (and yeah, Ken White is so wrong!) and the cleanest way was to really build up a new clean project in the lastest and up to date version of Visual Studio (VS2015 did not work sustainable) and just copy over the old project content which is just a few minutes work. This will save you a lot of headaches especially working in a larger team!
I tried the above solutions but nothing worked. I had to backup and remove the UWP project and recreate it from scratch.
I tried a couple of solutions.
Solution 1
Open the solution from Windows explorer and search for project.json files. Open all of them (If you have multiple) and make sure the required framework versions are there. I frequently switch between build 10240 and 17763 and I get this error frequently. (I switch between git branches that target different frameworks of UWP) So instead of adding the exact version I just added only the 10.0 part like this.
"frameworks": {
"uap10.0": {}
},
Now if your project.json files are ok, search for project.lock.json files. If you have one or more of those, delete them.
Now clean your solution
Close VS
Delete all the bin and obj folders.
Reopen the VS and try to run the app.
Solution 2:
Go to project properties
Change the minimum and target version to something else and do a clean build. Then put the actual versions and build again.
My Qt Windows desktop application crashes on first QNetworkAccessManager->get call. I get following error in the log.
Auto configuration failed
16100:error:02001015:system library:fopen:Is a directory:.\crypto\bio\bss_file.c:122:fopen('d:/openssl/ssl/openssl.cnf','rb')
16100:error:2006D002:BIO routines:BIO_new_file:system lib:.\crypto\bio\bss_file.c:127:
16100:error:0E078002:configuration file routines:DEF_LOAD:system lib:.\crypto\conf\conf_def.c:199:
It is something related to OpenSSL configuration, but I actually don't use (and don't need) SSL in my application. I know that OpenSSL library is loaded together with QNetworkAccessManager, but is there any way to disable it?
I can fix this problem by reinstalling openssl libraries like it is stated here, but this is not a good solution since I cannot force my customers to reinstall openssl on their systems because of my application. So I am looking for a better solution.
I already tried adding DEFINES += QT_NO_SSL into my project file but with no luck. Interesting here is that this is only happening after I deploy my application, it works smoothly from Qt Creator.
Important thing here is that I can manually manipulate crashing (on deploy systems) by modifying OPENSSL_CONF environment variable. If it does not exist or if it is set correctly, app won't crash, otherwise (env. variable is set to incorrect folder) app crashes.
Any ideas?
I have some problems deploying a simulation application to another computer. Up until a few weeks ago it worked fine to just check out the executable and required DLLs to the target machine. However, since recently I cannot start the application any more on the target machine without getting a windows (7) message stating that the application does not work correctly and needs to close. However, if I rename the application to any other name it works correctly. After renaming it back, it won't start again. It seems that the original name, which is "simspray.exe" btw, is somehow the problem.
Does anyone have an idea where the problem might be?
(I am really curious despite having the rename workaround)
The application uses some libs, mainly qt 4.8.3, qwt, nvToolsExtension (nvidia), glew.
We have tried the following already:
- use a completely fresh PC with newly installed Win7
- depends shows no missing dependencies
- no anti-virus program running, windows defender and firewall disabled, no other third party security tools
- application does not start from within visual studio either unless renaming the output exe name in the project settings
Thanks for any help.
If you have tried it on a completely fresh install then it can't be anything to do with the platform or environment, it must be something in the source code or build process.
If it worked fine up until a few weeks ago then it must be a bug introduced in the last few weeks. Can you check your source control system for changes made in that time?
Try varying the filename you rename to - do longer or shorter filenames have different results?
Try searching for code that uses the executable name in a stupid way, like this:
char buffer[sizeof(argv[0])+1];
strcpy(buffer, argv[0]);
or this:
int len = strlen("simspray.exe");
char *buffer = malloc(len);
strcpy(buffer, GetCommandLine());
Contrived examples I know, but both of these will buffer overflow yet magically appear to work if you rename the file to something of the right length.
I'm writing a C++ application using VS2010 on two dev computers - both are Win7 64bit SP1. I use git to sync the repositories.
On one of the machines the compiled executable (and also the test exec) stopped working with the following error, while on the other machine it works fine and I'm able to continue development.
The application was unable to start correctly (0xc000000d). Click OK to close the application.
I tried deleting the repository and cloning it again. I also made sure I have the same versions of Boost, git, Visual Studio. Also, I tried debugging (stepping in) but the error occurs before any line of code is reached.
Notice as far as I understand I'm tracking Visual Studio's solution\project configuration files as detailed here.
I'm at a loss, how would you debug this?
UPDATE 1:
Only the Debug version fails to run. The Release version runs fine
UPDATE 2: The executable that doesn't work does work on the other computer!
UPDATE 3: I've reinstalled VS2010 (exactly the same version) - didn't help. Surprisingly the compiled files are not the same size between the two machines.
I got the same problem as you mentioned.
My solution:
Clean the manifest file and rebuild
In the property page-> Manifest tool -> make sure "Additional Options" is set to nothing.
(I set it as "/validate_manifest" before).
Or you can try "Embed Manifest -> NO", rebuild and then set back to Yes. It sounds to be ridiculous, but it really works sometimes. I don't know why.
I got the same phenomenon suddenly without a warning on Win7 / VS2010 / C++. Debug App couldn't be launched, got 0xC000000D at initializing and loading multiple dlls. Found one base dll of my own responsible, played around with linker settings. Modifying settings, incremential rebuild -> app starts, rebuild all -> app crashes again. After setting "generate manifest" to "no" in the linker settings the sample app works, but the main app still crashes. After setting "generate manifest" to "no" for the most of my dlls -> the app starts in debug mode again. The stuff is very spurious, because some dlls need the modified settings others do not.
Have a look at the top two answers to this question
Program crashes with 0xC000000D and no exceptions - how do I debug it?
On the machine where it fails, try running the debug executable NOT under the debugger, and update your question to say what happens. If it crashes, are you able to then attach the debugger whilst the message box is still there and get a stack trace that tells you what function it is crashing in?
This is the weirdest thing....
Try deleting the "ipch" directory and then rebuilding.
Hope it works for you, I have wasted hours on this.
disabling/enabling precompiled headers fixed the issue for me.
I was facing crash on Debug x64 only - I guess it was related to an upgrade from boost 1.50 to 1.52, while keeping pch files.
in my case i got it working again by setting generate manifest to NO on all projects
I have changed "Embed manifest" setting to NO and then back to YES but it didn't help.
For me setting General->Platform Toolset to Windows SDK 7.1 for my program and all dependent libraries compiled with it helped.
It's the ipch just delete the entire folder and it will clear it up. I was confused for a while too.
I saw the error while using OpenCV library compiled with MSVC2010 in a project running on MSVC2015. Changing project configuration properties->General->Platform toolset from Visual Studio 2015(v140) to Visual studio 2010(v100) resolved the error.