I have Created a C++/CLI Console Application and I am using C Static Library(Multi-threaded (/MT)) In it.
Its Compiling fine but, when I try to launch it is showing Message Box
Saying
Unable to start ....\ManagedSample.exe
THis application has failed to start because the application configuration is incorrect. Review the manifets file for possible error.
I have Set clr option.
Typically this happens when no or the wrong C++ runtime library is installed.
Download and install the correct VC++ redist.
Eg. if you built your application with VS2010 SP1 use this package.
Related
I built an application that uses OpenXR with DirectX to display a simple scene in VR. As I'm tasked with implementing this in an already existing project, it's built using CMake, which works perfectly fine with Visual Studio 2019.
The application can run without any issues on the Windows MR Portal, as well as on the Oculus Rift S with the Oculus OpenXR runtime.
Now the next step is to get it running on the hololens. As I need an UWP project to do this, I created a .sln for the application I want to run on the hololens with CMake as follows:
cmake -G "Visual Studio 16 2019" -A x64 ..\.. -DCMAKE_SYSTEM_NAME=WindowsStore -DCMAKE_SYSTEM_VERSION=10.0
With this, I can open the project and compile it as UWP, works without any issues. Now, when I want to run the application to debug it, I get the following error:
Exception thrown at 0x00007FFD3CC83E49 in openxr_test_app.exe: Microsoft C++ exception: std::filesystem::filesystem_error at memory location 0x00000046791CCF50.
Error [GENERAL | | OpenXR-Loader] : Unknown failure: canonical: Access denied: "C:\WINDOWS\system32\MixedRealityRuntime.json"
After some googling, I found out that I might need to add the relevant capability to the Package.appxmanifest, so I added
<rescap:Capability Name="broadFileSystemAccess"/>
as well as
xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities"
and
IgnorableNamespaces="uap mp rescap"
to my Package.appxmanifest and enabled filesystem access for my application in the windows settings panel.
However, I still get the error above, I also tried to access other files on my PC (as I thought maybe system32 is a bit more restricted), but with no success.
I'm especially confused, because the OpenXR sample app from Microsoft works without any issues, and they did not declare the broadFileSystemAccess capability.
Are there any other ways to allow file access, or am I just missing something that I need to enable?
So as a quick follow-up, if anyone runs into the same issue: The problem here was a bug in the OpenXR loader that was introduced in version 1.0.10 of OpenXR.
Updating to OpenXR 1.0.11 solved the issue of the loader not being able to access the MixedRealityRuntime.json file.
I've written a quick C++ console app using VS2010. I'd like to run it via the remote debugger on the Windows Server 2008 platform, in order to determine why I can't enumerate the CLSID_AudioInputDeviceCategory on that OS.
The console app works on the XP and W7 platforms.
The remote debugger gives the following error when I first tried to run the console app:
The program can't start because MSVCP100D.dll is missing from your computer. Try reinstalling the program to fix the problem.
I did try just copying this DLL from my development machine to the target folder on the remote machine, but it returned an even more obscure message:
The application was unable to start correctly (0xc0000007b). Click OK to close the application.
I've tried installing the VS2010 C++ re-distributable on the target host. This has no effect. I'm out of ideas, does anyone have any suggestions?
Having spent some time on this problem, I've noticed that the Windows Audio service on server 2008 was disabled, but my query is more to do with getting remote debugging working on the server 2008 platform than solving my audio hardware enumeration problem.
Thanks to Errata, I had a look at
Project Properties -> Configuration Properties -> C++ -> Code Generation
I changed Runtime Library from Multi-threaded Debug DLL to Multi-threaded Debug (/MTd).
This allows remote debugging without having to rely on the correct debug DLLs residing on the remote machine.
I hope this helps someone out there!
I had this exact situation. I grabbed copies of MSVCP100D.dll and MSVCR100D.dll. However I grabbed them from system32 (the 32-bit version), which resulted in the 0xc0000007b error.
0xc0000007b apparently means invalid DLL, often architecture mismatch between program and DLL (i.e. x86 and x64). In my case I grabbed the wrong (32-bit) version of the DLL from my developement computer resulting in 0xc0000007b. After grabbing the file from SysWOW64, it worked.
I have a C++ application (quite complex, multiple projects) in Visual Studio 2008, that produces a single dll. Recently I switched to Windows 7, but had previously been compiling under Windows XP. Suddenly the dll in question cannot be loaded by another application, i.e. on a machine running Windows 2003 Server.
I've been trying various things:
I've installed the VC9.0 redistributable package on the server
Also copied various .dll's from that package to the application folder
The project is of course compiled in release mode
When I run depends.exe on the client machine, I do get the following error:
"Error: The Side-by-Side configuration information for "my_dll.dll" contains errors. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem (14001).
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module."
and the icon for shlwapi.dll has a red overlay icon.
This didn't happen when I was compiling under WinXP, so I'm guessing that there really is no problem with the .dll's on the client machine, but somewhere there is a reference to that particular version of some dll.
Does anyone know what would be the best way to resolve this?
Regards,
Daníel
OK I found it, and it turns out to be the same problem as described here:
vcredist_x86.dll and version 8.0.50727.4053
I had to compare the resources of the old binary with the new one, to notice the difference.
I installed XP on a virtual machine, updated it to SP3 and then tested a small program compiled with Visual C++ 2008 on my real computer - however it didn't start but outputted only an error saying that a problem had been detected and that a reinstall of the application (mine is 10KB in size and doesn't even have an installation) could fix the problem.
What is required to run programs compiled with MSVC 9?
Can I just include some dlls for it to work everywhere?
Either link statially against the runtime library (select multithreaded instead of multithreaded-dll) or follow tommieb75's advice and install the MSVC9 runtime redistributable (copying to system32 or to the application's folder works as well, but is not the way to go, afaik). For small applications with no need for an installer, I'd prefer the first option. Deploying runtime installers is annoying.
You could be missing the MCVC9 runtime library, try copying that over to the Windows System32 folder...
It may depend against which DLLs your project is linked. Inspect the assemblies manifest and check if those DLLs are installed on your VM.
What does your program contains? Dependencies on dynamic C/C++ runtime? Then you need to either include the C++ redistributable runtime DLLs in your app, or change the program to use the static C++ runtime. Similarly, do you use ATL? MFC? Custom 3rd party libraries? They all add dependencies to your executable and Win32 will refuse to load your application.
One easy step is to check with Dependency Walker what dependencies your application has.
It could be a dll you application links against. The depends tool is a must have in every programmers toolbox for debugging dll dependency issues.
If you have the commercial rather than express msvc edition, what you really should do is copy the msvcmon redist components to your VM, run the remote debug monitor there, and attach to it from your desktop dev environment. This page explains the basic principal. Because it sounds like your app is causing an exception on XP.
If you can't remote debug and if dependency checker does not indicate a dll issue, then you could look in the systems application event log to see if there is any more information there. Or try install Dr Watson as a post mortem debugger. Open a command prompt and enter
drwtsn32 -i
to install Dr Watson as the post mortem debugger, and
drwtsn32
to get a config screen allowing you to browse for the location of crash dumps. You can load crash dump files directly with Dev Studio 2005 and later. (I don't think Dr Watson ships with Vista and Windows 7 anymore).
all, I have a rather frustrating issue. The application in question has an MFC GUI that uses the classes available in the MFC Featurepack. This GUI uses an DLL that is developed in C++\CLI. Our company uses Cruise Control. NET (1.4.4 SP1) on Windows Server 2008 SP2 for continuous integration. Cruise Control is setup to use the version of MSBuild that comes with the 3.5 version on the framework.
The issue in question is that if I use the build that Cruise Controls creates, I receive the following error: "Unhandled exception at 0x7642fbae (kernel32.dll) in FormView.exe: 0xE0434F4D: 0xe0434f4d." After some digging, the issue seems to be that the GUI doesn't like the C++\CLI assembly.
The "gotcha" is that if I log on to the server, and, using PowerShell, execute the same MSBuild command, the build works. Any one have ideas?
The issue was how I was building the installer. It was a separate solution from the project's main solution, and was thus a separate task from the primary build. Therefore, the output assemblies got signed twice, and loader complained because the one the application wanted was no longer valid.
you could try and attach the process to the visual studio debugger.