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.
Related
I am reproducing the following behavior in VS2008 (native C++):
attach to an executable that consumes a custom dll (for which I have the source)
debug the code from the dynamic lib
encounter an access violation error (probably caused by the code in the executable - closed source)
break on access violation error with the attached debugger
After this, no matter how many times I reattach, rebuild, restart the application, computer, any breakpoint I will set in the .dll source code becomes inactive (No executable code associated with this line is the alleged cause, according to VS).
I suspect this is an issue with VS2008, as I did the same on a different machine and now I have two machines where debugging is no longer possible.
Are there any recorded solutions of this issue? What can be done to overcome it?
What I have done:
deleting everything (the entire solution, pdbs, binaries, etc.) and starting with the code from scratch (cloning the latest version from the repository)
restarting the machine
changing the machine (it worked once, until the error occurred, then the other computer exhibited the same behavior)
What I cannot do:
change compiler/VS version
debug the executable (sadly no source code available and lack of assembly skills)
The root of the issue was more subtle. Although the project was intended to be native C++, I have found that on the configuration I was testing the code, the entire project was built with CLR support.
When attaching to the application the first time on any machine, in native debugging mode, the breakpoints would trigger. However, when encountering the native access violation error, these breakpoints became permanently inactive thereafter. After deciding to check what happens if I let the debugger attach in auto mode, I have discovered that the breakpoints became active and hence found out that all code had been compiled with the /clr flag except for the entrypoint in the consumed dll, which had no CLR support.
The question here is why VS2008 behaves like this and does not directly disable breakpoints whenever one attempts to debug a managed context using native debug settings.
TL;DR: check if your C++ project is built with CLR support and attach either as native or managed, depending on your needs. Alternatively, if only some of your files require C++-CLI usage, enable the /clr flag only for those. It is more often a better choice since C++-CLI often clashes with certain native libraries (e.g. not std::mutex support, linking against native static libs Linking unmanaged C++ DLL with managed C++ class library DLL, etc.).
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.
My basic issue is this: my program (MyProgram.exe) has a dependency on a DLL from another program (OtherProgram), and I'm trying to avoid repackaging a new DLL every time OtherProgram updates. I'd like to have MyProgram.exe link in OtherProgram's DLL when it launches, but I'm not completely sure that Windows allows for this. So if there is some kind of workaround that would also be acceptable.
And just for some background, the platform is Windows 7 x64, and MyProgram.exe runs fine when I create a symlink in the MyProgram.exe project directory to the DLL in OtherProgram's install directory. When I try to run it without the symlink, I get the "program can't start because OtherProgramDLL.dll is missing from your computer" error.
Any advice or links to relevant info is greatly appreciated!
EDIT: Clarification: the DLL is not linked at compile-time, this issue crops up at runtime
There are two types of dynamic linking in the Windows world:
Load-Time linking is when a DLL is loaded automatically when your program starts up. Windows finds this DLL using a specific algorithm I'll discuss below.
Run-Time linking is when you specifically load a DLL by calling LoadLibrary in your code. Similar rules apply as to how the library is found, but you can specify a fully-qualified or relatively-qualified path to control the search.
In the case of Load-Time linking, MS recommends that your program's DLLs are stored in and loaded from the same directory where your application is loaded from. If this is at all workable, this is probably your best option.
If that doesn't work, there are several other options, outlined here. One is to leverage the search order by putting the DLL in either the working directory or the directory where the application was loaded from.
You can change the working directory of an application by:
Create a shortcut to your application.
Bring up the shortcut's properties
Edit the "Start in" property with the directory where the DLL is located.
When you launch your application using the shortcut, it will load the right DLL.
Other options for load-time linking include:
Adding a manifest to your application which specifies where your dependent assemblies are, or,
Setting the PATH.
You could use LoadLibrary, but you would need a way to guarantee the DLL's location. This Wikipedia article provides good example on how to use the DLL after it has been loaded.
You can add the directory where the dll is located to the PATH environment variable.
I have struggled with the same problem and also found a dead end with the suggested methods like LoadLibrary, SetDllDirectory, Qt's addLibraryPath and others. Regardless of what I tried, the problem still remained that the application checked the libraries (and didn't find them) before actually running the code, so any code solution was bound to fail.
I almost got desperate, but then discovered an extremely easy approach which might also be helpful in cases like yours: Use a batch file! (or a similar loader before the actual application)
A Windows batch file for such a purpose could look like this:
#echo off
PATH=%PATH%;<PATH_TO_YOUR_LIB>
<PATH_TO_YOUR_APP_EXE>
/edit: Just saw #SirDarius comment in Luchian's answer which describes that way, so just take my batch code bit as a reference and all credits go to him.
I have the same problem with one application I am working on.
I do not want to use runtime loading because there are tens of functions I would need to manually create function pointer for.
Mr Dibling's mention of manifest file opened a new door for me but I sadly found out that the oldest version of windows that supports the feature is Windows 7. It won't even work on Vista.
Long story short, a friend familiar with Windows Application development told me to look up Delay-Loaded DLL, which turns out to solve the problem perfectly with minimal effort. It delays the loading of DLL library to either the point you manually do, or the first time its function is called. So you just need to add your DLL path to the search path before that happens, where SetDllDirectory helps.
Here is the steps to make it work:
1) Specify the DLL to be delay-loaded to linker, either through your makefile, cmake or VS property page (Linker->Input of VS2015)
2) Call SetDllDirectory at the beginning of your program, before any call to the DLL is made.
Delay-loaded DLL is supported all the way back to VC6.
SetDllDirectory is supported after XP SP1.
Use Symbolic Links to the 3rd Party Executables
I found the approach advocated by Aaron Margosis useful. See:
Using NTFS Junctions to Fix Application Compatibility Issues on 64-bit Editions of Windows
Essentially, create symbolic links to each of the dependent 3rd Party executables. Place these symbolic link files in and amongst your own dependent executable files. Except for filename changes to the targets, the 'soft' symbolic links will resolve the load-time dependencies even as the target of the links are changed by future updates.
This shakes my understanding of computers and operating systems on a level that makes me very uneasy. I have just spent about an hour entering different iterations of compile commands to g++ and in my exasperation I renamed the executable which kept having the delay from game.exe to gameg.exe and all of a sudden the problem vanished.
Here's some more background: I was noticing recently that when I ran my Eclipse unit test build, when I start with an SDL enabled test it would open the SDL window and freeze for about 20 seconds before being able to get the test started. On subsequent tests (which call SDL_Quit() and re-initialize SDL as part of the test process) this delay is not present. Now I have ascertained that ONLY when the executable is named exactly "game.exe" does this happen! I rename it to any other filename and it goes along running tests happily, initializing the SDL system within a second like it usually does. I had assumed before that there must be some kind of bug that was causing my Eclipse build to have this behavior which wasn't present in the makefile build, but it turns out if I take the eclipse build and rename its executable (the project folder it's in is called game hence game.exe) it doesn't exhibit the behavior.
Likewise I take my makefile build (whose filename is entropy_unittest_disp.exe fyi) and rename it to game.exe and it begins to do this. I rename it to game and it also does it (I am running from mingw's bash.. when not with .exe extension, explorer doesn't know it's an executable). However I changed it to game.exx and it worked normally.
WHAT IS THIS BLACK MAGIC? Why should a program function differently depending on its filename??? I do query argv[0] and i actually do it to print to console its value (for debug purposes) but unsurprisingly it just prints the program and its path. No logic is ever performed on it in my program.
I tried to run GDB to find out where it is freezing but once I press Ctrl+C GDB simply exits.
does anybody have any idea what this might be caused by? A virus?
edit: I downloaded this demo from this site: http://www.sdltutorials.com/sdl-opengl-tutorial-basics/
extracted it, renamed the file to game.exe, and yup, same thing happens. WHAT IS THIS? I'm going to try running dependency walker next to see if something's trying to hook into it.
I'm assuming you have either a AMD (ATI) or Nvidia graphics card with their official drivers.
Chances are, game.exe is the executable name for an actual game released and your drivers are running special optimizations for the "game" or loading the Crossfire or SLI profiles for this game. A quick Google search seems to tell me that Resident Evil 4 calls their executable "game.exe."
I recommend taking a look at this link for further details as to what may be happening:
http://www.kn00tcn.net/site/ati-catalyst-profiles/
not sure how to reply to steven's comment on the top answer, but regarding driver profiles, it's just a basic brute force check of .exe filenames
some games are guaranteed to be in a specific sub folder, so the driver looks for where the exe is located, such as '\team fortress 2\hl2.exe'
but since most games let you pick what folder name you're installing to, & a lot of the time the exe is in that same root folder, the drivers have no choice but to blindly assume gameX.exe is going to be gameX
a nice 'side effect' of this is you can force other game profiles on any game for troubleshooting purposes, or to try to enable CF/SLI scaling
so always try to make sure that your executable has an original name to know that the gfx driver isnt attempting to run 'optimizations' made exclusively for other games
Could this be due to Anti virus software running on your OS? Certain files are commonly used in Virus "Game.exe" could be one of them and hence additional care from OS / AV to ensure that it is safe
Test it in clean windows, without any extra software installation, if it work fine, then maybe you have some protection software like Anti-virus or sandbox , ... , if you have any of this software disable them, and test again
Check to see if game.exe is listed in the Image File Execution Options registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options. It can be used to launch a particular program as a debugger for an application with a particular name. (More info on Image File Execution Options)
An EXE will behave differently based on its name due to AppCompat Shimming. Check the loaded module list and see if there are a bunch of DLLs that start with "ac" loaded into your app.
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.