On Wed, Apr 15, 2009 at 7:57 AM, Carl Zmola
This seems like it has something to do with what is loaded by default withing an development environment.
Thats what I thought also when I saw it run with dependencywalker. Maybe it was trying to use a different DLL when loaded through another program?
Also, since this is windows, rule out the standard suspects.
Break out dependency walker, and check what dll's are being loaded. Debug and release dll's may be different, and this could possibly cause a problem. Also it might be possible, in the release build, some dll is not available or even some weird manifest issue that prevents the loading of the correct dll. This usually appears at start but who knows.
Ok, what do I look for in dependency walker? I run it and only see 4 errors: GetProcAddress(0x7C800000 [c:\windows\system32\KERNEL32.DLL], "FlsAlloc") called from "c:\windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_6f74963e\MSVCR90.DLL" at address 0x78543ACC and returned NULL. Error: The specified procedure could not be found (127). GetProcAddress(0x7C800000 [c:\windows\system32\KERNEL32.DLL], "FlsGetValue") called from "c:\windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_6f74963e\MSVCR90.DLL" at address 0x78543AD9 and returned NULL. Error: The specified procedure could not be found (127). GetProcAddress(0x7C800000 [c:\windows\system32\KERNEL32.DLL], "FlsSetValue") called from "c:\windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_6f74963e\MSVCR90.DLL" at address 0x78543AE6 and returned NULL. Error: The specified procedure could not be found (127). GetProcAddress(0x7C800000 [c:\windows\system32\KERNEL32.DLL], "FlsFree") called from "c:\windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_6f74963e\MSVCR90.DLL" at address 0x78543AF3 and returned NULL. Error: The specified procedure could not be found (127). Are those something that could cause this or that I should be worried about? The main DLL's I'm linking against according to dependency walker are KERNEL32.DLL, MSVCP90.DLL, MSVCR90.DLL. In addition, as I mentioned, the program runs fine with depends debugging it. Also, as I've found by printing debug text, the crash happens on a new/allocation call. However, it is not the first new call, and changing some things can cause the location of the crash to move. I.e., I changed from /MT to /MD compiles as per Neil's suggestion and the crash moved to a slightly later new call.
Since DateTime is a library (not header only), confirm that both a debug and release build exist, or at least that the library that your executable is using exists and that the dll's that the datetime library is linked against are compatible with the ones that your executable are using.
As far as I can tell, this is all functioning as it should. I'm using Boost 1.38.0 downloaded through BoostPro. I selected the options to download the static libraries first and tried /MT. Then I re-did it and downloaded the DLL's, and changed it to /MD. I have had some linker errors, but it was usually when I tried to link release-compiled code with debug libraries, or tried to use /MD without having the DLL version downloaded.
Carl
Thanks Carl... Any other things to try? Jared