I'm attempting to run KCacheGrind on some results of callgrind. Basically the codebase is a plugin container that launches a shared object to run a specific function. Upon using Callgrind to profile this application, I can see the costs at the function level, but not at the source level.
I can see at the source level with the plugin container code, before it launches the SO, but I can't see any code contained in the SO that was launched.
I know I'm compiling with debug symbols on, but for some reason I am unable to see the dynamically loaded SO source code.
Thanks,
I ran into this problem too. The way to fix it is to stop the host application from unloading the plugins before it exits. In my case I was trying to profile C modules for Lua and Lua was unloading the modules when the VM exited normally. To fix this issues I had the script call os.exit() to do a forced shutdown.
Either disable plugin unloading in the plugin container, or create a plugin the allows you to force the application to exit (calling _exit(0)).
Related
qgif4.dll, qjpeg4.dll, qtiff4.dll all implement these functions:
qt_plugin_instance
qt_plugin_query_verification_data
dumpbin possibly isnt smart enough to see if any functions in qgif4.dll, qjpeg4.dll, qtiff4.dll could be called and thus are needed by the application.
To be precise: I ran dumpbin and it said our exe doesn't depend on any of the above dlls's, but my manager still has doubts whether or not the qjpg4.dll is needed. Is there a way to tell for sure before shipping?
Of course we need to supply all dlls needed by our app. But we want to supply what is essential only, since the app has to run on a stripped down embedded version of Windows XP with size constraints: all is run from virtal RAM disk.
Those are Qt plugins. They are loaded on the fly by Qt depending on which image formats you use in your Qt code.
You should be able to deduce which ones are needed by looking at which image formats you load with Qt code.
You can also run your program while Process Monitor is running. It will trace, among others, all loaded DLLs, so you will know that those loaded DLLs are needed (needed for the code you ran during that session. This method does not guarantee that some other code of the program that you did not execute in that session does not depend on an other image plugin)
When launching my app, I'm getting the below error dialog. I understand this indicates a problem loading the runtime library. The problem is, I'm not seeing any way to get more specific info. Which library? What was the exact problem it had when loading? etc.. System event viewer doesn't have any entries for it. Are there any tricks to finding out exactly which library it was trying to load when it hit the error and what the specific problem was?
Microsoft Visual C++ Runtime Library
Runtime Error!
Program: exe path
R6034
An application has made an attempt to load the C runtime library incorrectly.
Please contact the application's support team for more information.*
My current approach for dealing with runtime lib dependencies is to scan the install directory, extracting out the embedded manifests for the .dll and .exe files and then generating .config and .2.config files to re-direct to the minor versions of the runtime lib I'm shipping with. In the past this has always gotten things working. Not so in this case.
This might be complicated somewhat by the fact that the calling code is native C++ but some of the DLLs use .NET. I'm calling a C++ API, but under the hood it ends up utilizing some DLLs which themselves use .NET.
Use SysInternals Process Monitor to monitor file system access. Filter on process name and operation (CreateFile) to see what DLLs the process can't locate.
It could indicate a wrong version of msvcr*.dll.
You could try Dependency Walker (http://www.dependencywalker.com/) to find out where it's being linked.
Make sure you have a debug version of the code you're trying to attach to. On the Debug menu, select Attach to Process. Use processID -
Also check this -http://support.microsoft.com/kb/235434
Resolution 1
You should be able to attach to the process using Task Manager:
Enable just-in-time debugging (JIT):
In Visual C++, on the Tools menu, click Options.
On the Debug tab, make sure that Just-in-time debugging is selected.
Run Task Manager and select the process to attach to. Right-click and select Debug.
Resolution 2
Run Task Manager and get the process ID for the process you want to debug.
At a command prompt enter the following:msdev -p
This will start Visual C++ and will attach to the process specified.
Is it possible to recompile an MFC DLL while its "client" executable is running, and have the executable detect and pick up the new changes? If it's possible, is it foolish? Being able to recompile the DLL without restarting the exe would save some time in my coding workflow. I am using Visual Studio 2008, code is written in native C++/MFC. My code changes are entirely contained in the DLL, not the EXE.
Thanks!
Unfortunately, unless the executable has support for hot-swapping DLLs, you can't do it. The standard DLL loading mechanism in Windows will load it either at the start of the process or at first use of a function exported by the DLL and will not watch the file for changes in order to reload it. Also, depending on how the DLL is loaded, the file might be locked for changes.
You will have to stop your client executable before recompiling.
Yes, it's possible. You'll need to make sure the executable explicitly loads your DLL (via LoadLibrary). If your executable implicitly loads your DLL you'll have the issues that Franci described.
To update the library while the executable is running:
Define some convention for staging the new version of the DLL. It could be in a separate folder, or with a different file name/extension.
Have a means of checking for a new version of the DLL. This could be in response to some specific gesture in the user interface, or you could monitor the directory for changes from a background thread.
When you see a new version, unload the old version (FreeLibrary), then delete it and move the new version to the desired location and reload it (LoadLibrary).
If your DLL implements any COM objects, let me know and I'll give you some additional tips.
I am building a project in VS2005 and several of my DLLs are failing to register. The error message I am getting in Visual Studio is:
Project : error PRJ0019: A tool returned an error code from "Registering ActiveX Control..."
which is nicely vague. When I register the DLL manually through the command line (using regsv32.exe, I get the following error:
LoadLibrary("test.ocx") failed - This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix the problem.
I ran Dependency Walker (depends.exe) on the culprit .ocx file but it isn't showing any obvious problems.
I have also done a re-build but I'm still getting the same problem.
Any suggestions as to how I could determine the cause of this failure to register?
Microsoft had recently released a Security Update for ATL (KB971090). It is un update on top of MSVS2005sp1 and it's both compilate-time and runtime compatibility breaker. Check if your building environment has this patch.
References:
ATL Security Update:
http://msdn.microsoft.com/en-us/visualc/ee309358.aspx
Breaking changes in ATL:
http://msdn.microsoft.com/de-de/library/ms235654.aspx
And this is a must read:
http://tedwvc.wordpress.com/2009/08/10/avoiding-problems-with-vc2005-sp1-security-update-kb971090/
Most probable is because the embedded manifests. You should take a resource explorer application and check your DLLs for the embedded manifests. It might be that one of the dependent DLLs (or your DLL) require some versions of other DLLs which don't exists.
I got this message: "This application has failed to start because the application configuration is incorrect." in case of embedded manifest mistmatches.
Probably the easiest way to troubleshoot this whole category of problem is to install Process Monitor from microsoft.com.
Process Montior lets you observe the system calls processes are making, and in this case you will be able to see if some system call is failing. For example, if you are lacking a dependency, then a CreateFile() call will be seen failing with a DLL, OCX, etc. as the filename.
Launch procmon and configure the filter to exclude events other than from regsvr32.exe, reproduce your test case, and then check the log. Look for NAME_NOT_FOUND errors in the return value column.
Do you have the C++ Redistributable Package Installed?
There are several things you can try:
try regsvr32 w/ fusion log enabled (fuslogvw.exe - it works for unmanaged dlls as well). This would give you a bit more information than depends on what external dependencies are loaded, where are they loaded from and what errors were hit.
copy the .ocx and its dependencies to the root or a first level folder and try registering from there. I don't remember details, but there was an old problem with registering a COM dll from within too deep of a path.
run regsvr32 under WinDbg. Set a breakpoint DllMain and see if it does anything funky.
If you never break on DllMain in WinDbg, set a breakpoint on module load for your dll and once it's hit, you can either step through LoadLibrary, or just set a generic load library breakpoint and check every dll after that.
I am trying to build a Windows service with MingW. It need thread safe exceptions, so I added the linker flag -mthreads. The application works fine from the command-line, but when I try to start it from services.msc, the 1054 error ("The service did not respond to the start or control request in a timely fashion") is raised. The service starts if I re-build it without the -mthreads flag. How can I get this working with -mthreads?
I suspect -mthreads is bringing in a dependency on a DLL, and that DLL is not on the path when it's running as a service. In my cygwin environment, if I compile a trivial program with "-mno-cygwin -mthreads", I get a dependency on MINGWM10.DLL, which certainly wouldn't be on the path when running as a service. If I try running it with no PATH set, it crashes as it starts to load (and leaves a turd in the Application event log).
I'd be bringing up your exe in Dependency Walker (http://www.dependencywalker.com) to see what you're loading at load-time, and check your Windows Event Log to see if there are any hints there. You're probably going to need to put a copy of the DLLs it needs alongside the executable.
You need mingwm10.dll in the working directory or in [edit: system, not per user] PATH, because C++ programs compiled with -mthread option have that dependency. If you're pretty sure exception will never be thrown by your code nor propogate through your stack, use -fno-exception instead of -mthread to resolve the dependency.
I wonder if you can debug it when it runs as a service. There must be something spooking your program when service host runs it. Perhaps try to attach a debugger to svchost.exe, at least you can see what modules are loaded and maybe which exception causes the crash.
Is your application even starting up at all? Put a call to OutputDebugString (or equivalent) at the start of your main function to see if it even gets that far. (Grab DbgView from SysInternals if you don't have it already.)
If it doesn't get that far, we start checking for the obvious: is it a matter of the application not finding the runtime DLL? It could be that you have the regular runtime in its PATH, but it can't find the MT version. That could explain the behaviour you describe. You may need to copy the MT runtime or update the PATH accordingly.