How can we trace a compiled application from windows 7. I can see in the event viewer that some DLL files which my program is trying to fetch are causing problems but I can't figure out why.(This is with qtcored4.dll)
You can solve DLL loading problems with Dependency Walker, either by looking at the exe (just open it) or tracing DLL load process by starting profile.
Related
I have a project in visual c++ where I am referring some external DLL.
I have already included the lib directory in linker section and mention it in the input section of the linker and also included the same in c/c++ General Additional Include Directories section.
Thus the project compiles successfully but whenever I try to run it; it fails with an error "Application was unable to start correctly" but if I see the output section it seems everything is loaded correctly but against that particular Dll it says that "Cannot find or open the PDB file".
How to fix this error so that I can run my program. It is an MFC program running in Visual Studio 2010.
when I run the program through the Dependency Walker, most of the API-MS-WIN-CORE-HEAP, FILE, and EXT-MS-WIN-SESSION USERMGR -l1-1-0.dll many similar to this are unavailable. I even tried to repair the visual studio it didn't work. Is there any idea how to go about it
0x0000007b sounds familiar to me.
Most likely that is due to 32/64 bit library mixture you are linking with.
Either you are building for x64 and linking with a win32 external library or vice versa.
In your Visual Studio project settings separately configure platform architectures you are compiling for and then you can choose the profile which you are actually compiling for.
I am using visual studio 2010 under Win7-64bit to build an application with openCV. I finished development and build the release version without error. I also successfully run the program in debug mode. I then move the .exe file to other directory in the same computer. I run it in cmd.exe and I got error warning: Error opening file <../../modules/highgui/src/cap_ffmpeg_implhpp:537>
I guess there are some dependence with some libraries of openCV but I don't how to solve it. My final task is that I can use that .exe in another computer under Win7 directly. How to do it?
I found a similar question here. But I don't have .dll file built, so what should I do to solve this problem?
Building an OpenCV app with shared libs (DLLs) require the DLLs to be available (same folder or in lookup path) to the exe when it is run.
If you are using static linking then you don't need any of the OpenCV DLLs to be reachable. However, due to licensing issues, ffmpeg is linked dynamically even when the rest of the libs are linked statically, and thus, you need to have the ffmpeg DLL available for the exe. It is called something like opencv_ffmpeg*.dll.
Note that this is only needed if you are using highgui related functionality.
I'm not a a very experienced Windows developer, so I hope this all makes sense.
I created a Managed Assembly DLL using Visual Studio 2010. The DLL (Plip.dll) contains a C++ class that is using System.IO.SerialPort class to do some simple communication over a serial port.
In a second Visual Studio project I created a simple GUI that uses the class found in Plip.dll. In my GUI project I have the line : #using "Plip.dll" . In the Project Properties I set the 'Resolve #using References' value to the correct location of Plip.dll. The GUI builds just fine. If I copy the GUI.exe and Plip.dll to the same folder, the GUI runs just fine on my computer.
The problem I am having is that when I copy both files to a second computer, I cannot get the GUI executable to run. I get the following error : "System.IO.FileNotFoundException. Could not load file or assembly "Plip.dll" Vesion=.... ". I get this error even though both the exe and dll are located in the same folder.
Any suggestions on how to resolve this issue? Is there some option I need to set in my GUI project to load the DLL correctly at run time?
I suppose the problem is not the Plip.dll, but it's dependencies.
Use Dependency Walker on the second computer to see if it needs any other dll's (they might be installed in System folder or in %PATH% on your development computer, but not on the other).
If this second computer doesn't have Visual Studio installed, you are probably missing Microsoft Visual C++ 2010 Redistributable Package (you need to install it on the other computer)
Also make sure that you compile in Release because debug builds need debug dependencies.
I found the answer to this problem to be much simpler than Dependency Walker (but admittedly, that was fun to look at).
In my case, the issue was a mis-match between the .DotNet versions in the DLL and with the application's .net version. This was caused by building the "class library" using .DotNet 6.0 (dot net core?).
Instead, the entire class needed to be re-built using "Class Library (.NET Framework)"
enter image description here
I wrote an article on this problem.
https://keyliner.blogspot.com/2022/09/visual-studio-c-linked-dll-exception.html
I have a solution (Visual Studio 2008) that contains a couple of products. One of these products contains a control that was developed by a colleague that requires loading of a dll. The dll must be loaded when the solution is loaded so that I can view and use the control. However, I am getting errors in the error window saying the control is not defined. When I look on another system (Windows XP Pro) that has VS installed and uses this product and dll, it works fine. However, when I try to load it on my system (Windows 7), I get the errors.
I used Process Explorer on both systems to verify that the dll in question is being loaded. On the XP system where everything works fine, I can see the dll needed is being loaded from C:\windows\system32. I have the dll in the same location (c:\windows\system32) on my Windows 7 box. However, when I load the solution on the Windows 7 box, I can see through Process Explorer that the dll does not load. I know c:\windows\system32 is in the path and I can see other dlls from windows\system32 have been loaded by the visual studio executable image. Why wouldn't this dll be loading? Is there some logging mechanism within VS that will tell me at load time (when I load the project containing the control) why the dll will not load?
Is this a Windows 7 thing? Should I not be putting a developed dll in windows/system32?
Help is appreciated.
Thanks.
Hmm the only thing i have in mind is if the .dll is 32bits and you are making a 64bits application they could be incompatible.
One handy trick I use all the time to deal with dll loading issues is to turn on fusion logging. With that, loading exceptions will be logged to a file, where you can see what might be missing or where the framework is probing for it.
To turn it on, set the following registry keys:
HKLM\Software\Microsoft\Fusion\ForceLog registry value to 1 and HKLM\Software\Microsoft\Fusion\LogPath registry value to C:\FusionLogs (this path must exist)
More info on it:
http://www.hanselman.com/blog/BackToBasicsUsingFusionLogViewerToDebugObscureLoaderErrors.aspx http://msdn.microsoft.com/en-us/library/e74a18c4(v=VS.90).aspx
I have an error that I suspect might be caused by different versions of the CRT being loaded on two computers running Windows 7. How do I determine which version of MSVCR90.dll in the winsxs folder is being loaded?
My program is a DLL being loaded by another EXE. It is compiled using Visual Studio 2008 SP1.
As Al Kepp answered, you can use Dependency Walker, "Depends.exe". For DLLs that are dynamically loaded, the best way is to profile the application as it loads your library.
In Dependency Walker open the EXE, not your DLL. Then click "Profile-->Start Profiling". If the application requires arguments you can provide them in the window that opens, otherwise just click "Ok" to launch the program. Once the program is open, use it in the normal way so that it loads your DLL. Now that your DLL is loaded, you should be able to browse the tree in Dependency Walker to see which versions of the CRT are being used.
If you can't see the version, ensure that the full paths are shown in the tree by clicking the "C:\" button.
You can also see which version of the CRT the application or library is requesting by checking the manifest, which is generally, but not always included in the DLL or EXE. in Visual Studio, click "File->Open->File..." and select the EXE or DLL. Open the RT_MANIFEST resource and you should see some XML which lists the CRT as a dependency and the version.
Most applications using these language libraries in DLL files use simply the latest version of those DLL in Windows directory. If you for some reason need some specific version, the easiest what you can do is probably to put those correct files to the same directory as your exe.
You can use Dependency Walker application to see which DLL files are loaded into your process on startup. You can download it from Microsoft site for free.