I'm developing an application in 3D in a win 7 64bits machine, in visual C++ 2008. All runs correctly. When I check this application in a clean machine in a VMWare virtual machine with XP 32bits (hardware 3D activated) or in a machine of a friend of mine, the application fails.
The behavior of the application is different (into the clean machine) depending of the compilation (debug or release) and if I compile with MD(d) or MT(d)
My question: it is possible to debug the application into the clean machine? Exists a central log like /var/log/message but in windows? How to check what dll are in use in my dev machine, in order to compare with the installed in the clean machine?
Thanks!!
If its on the same network you can you the remote debugger ! But you may first want to check if its not a 64bit app on a 32bit OS.
Make sure the bitness is correct and that the correct VC++ distributable is installed on the test machines.
If that doesn't help, then try this for fast debugging:
Grab the debugging toolkit from MS (http://www.microsoft.com/whdc/devtools/debugging/default.mspx)
Install it on your development machine.
Copy the installation folder to the machine you want to debug on.
Copy / Install your program to the machine, remember the *.PDB files.
Start WinDBG from the debugger folder and use the 'File->Open executable' command to start your app. WinDGB will break fast and you can debug from there.
If you want break points and such, look up the commands in the WinDBG help files.
You could try running your app under dependency walker (www.dependencywalker.com). If the problem is missing or incorrect dlls, dependency walker will show it up very quickly.
On XP you can use the built-in debugger, ntsd.exe. it's basically like windbg lite and requires no additional install.
Related
I am on a Windows VM which has eclipse installed.
I connect to a remote centos machine using putty (yes command line)
I work on a large C++ makefile project there.
I have learnt to use gdb within putty and everything is ok.
Is there any way I can use Eclipse present in my Windows to debug the C++ makefile project present in my remote CentOS machine ?
I have the following installed on my windows VM
Winscp
Putty
Eclipse
I wont be able to install anything else.
I also wont be able to install anything else into my centos machine unless I can justify the reason.
I believe this is NOT an exact duplicate.
I searched high and low for a solution to this, most answers seem to be for a different application or requires some additional installations or maybe the instructions are not clear.
Please provide me a step to step guide as I am new to Eclipse, and 2yrs old into linux.
Basically a windows programmer, I have seen a VS solution to remote debugging, but I wont be able to install VS into my remote machine so thats out of question.
So the above ... or ... any GUI (Visual Studio kind) type solution that would make the remote command line GDB ... a breeze.
Recently I wrote a program with VS2019, invoking Tesseract OCR dll compiled in C++ (x64) and display result on a .NET Windows form. Everything works fine on my Windows 10 dev PC. When deployed to Windows Server 2012 (x64), it crashed, complaining that the C++ dlls are not found.
What I tried:
Install vc_redist.x64.exe from Microsoft, it's still not work. (Maybe not enough?)
Run a simple .NET windows form program on that server, and it works well. (It's not a .NET problem)
Update:
I used Dependency Walker that #Fenixil suggested, and the dlls below are not found:
API-MS-WIN-CORE-KERNEL-32-PRIVATE-L1-1-1.DLL
API-MS-WIN-CORE-PRIVATEPROFILE-L1-1-1.DLL
API-MS-WIN-SERVICE-PRIVATE-L1-1-1.DLL
MF.DLL
MFPLAT.DLL
MFREADWRITE.DLL
API-MS-WIN-CORE-SHUTDOWN-L1-1-1.DLL
EXT-MS-WIN-NTUSER-UICONTEXT-EXT-L1-1-0.DLL
IESHIMS.DLL
SETTINGSYNCPOLICY.DLL
WLANAPI.DLL
Those dlls can be found in my dev PC, in C:/Windows/WinSxS, multiple files in same name under different directory. Do they belong to some Windows SP update, or are they in the Win10 platform API? What's the best way to install them instead of simply copying them to production server?
There are multiple versions of vc_redist, you need to provide one that is used in your application. Here is some discussion with vc_redist not found, might be related to your issue.
You can use Dependency Walker tool to check which dlls are missing in the system
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 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).
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.