Is it correct that either method will only work when the CRT is dynamically linked?

I have a program which needs to be statically linked to the CRT and your solution does not seem to work. Is there any way to get it to work for static linking?

I also found the following from a article on Codeproject which seems to be doing the same in just 1 line of code. Is there a difference between your method and this one?

LONG WINAPI RedirectedSetUnhandledExceptionFilter(EXCEPTION_POINTERS * /*ExceptionInfo*/)
{
// When the CRT calls SetUnhandledExceptionFilter with NULL parameter
// our handler will not get removed.
return 0;
}

int main()
{
::SetUnhandledExceptionFilter(OurCrashHandler);

CAPIHook apiHook(”kernel32.dll”,
“SetUnhandledExceptionFilter”,
(PROC)RedirectedSetUnhandledExceptionFilter);

// Code that crashes
}

after a half a year of using VS2010 i switched back to VS2008, cause i found VS2010 mostly unusable. It’s much slower, unstable, compiling and linking is slower, the new data format of Class viewer and browser information is big shit, runtime has errors or unforseeable effects… and so on.

Now that i had this manifest hell again, i found out a easy solution for that problem. I know, it’s looking horrable, but its the most efficent way to overcome this ERROR, that Mircosoft made:

Edit the crtassem.h in C:\Program Files\Microsoft Visual Studio 9.0\VC\include directory to always define _BIND_TO_CURRENT_VCLIBS_VERSION.

Like this:

#if !defined(_BIND_TO_CURRENT_VCLIBS_VERSION)
#define _BIND_TO_CURRENT_VCLIBS_VERSION 1
#endif

or change the original

#ifndef _CRT_ASSEMBLY_VERSION
#if _BIND_TO_CURRENT_CRT_VERSION
#define _CRT_ASSEMBLY_VERSION “9.0.30729.1″
#else
#define _CRT_ASSEMBLY_VERSION “9.0.21022.8″
#endif
#endif

to

#ifndef _CRT_ASSEMBLY_VERSION
#if _BIND_TO_CURRENT_CRT_VERSION
#define _CRT_ASSEMBLY_VERSION “9.0.30729.1″
#else
#define _CRT_ASSEMBLY_VERSION “9.0.30729.1″
#endif
#endif

Theres one more thing:

If you really have a manifest problem and guessing why, just let windows trace the loading of the application with

sxstrace Trace -logfile:log.bin

start your program, then

sxstrace Stoptrace

and convert the logfile to human readable format with

sxstrace Parse -logfile:log.bin -outfile:log.txt

With this, your can see a protocol of loaded and found sxs-dlls, manifests and so on. Very interesting…

Good luck!

BOOL bProt = VirtualProtect(pOrgEntry, jmpSize,
PAGE_EXECUTE_READWRITE, &dwOldProtect);

I made tests on Windows XP and Windows 7 OS - result is the same.

I’ll try to do a repro-case for you.

fatal error C1083: Datei (Include) kann nicht geöffnet werden: “msclr/marshal.h”: No such file or directory

can u help me please?

thanks for that very helpful advice. I spend day and days investigating that matter… without a solution.

Your my hero!

Greetings,

Dirk

Dependent Assembly Microsoft.VC90.DebugCRT,processorArchitecture=”x86″,publicKeyToken=”1fc8b3b9a1e18e3b”,type=”win32″,version=”9.0.21022.8″ could not be found

I’ve followed this and I must still be doing something wrong:
http://blog.kalmbach-software.de/2009/05/27/deployment-of-vc2008-apps-without-installing-anything/

It should really not be this difficult!

Build started 11/30/2010 10:52:33 AM.
Project “BLAT01.proj” on node 0 (Build target(s)).
BLAT01.proj(37,5): error MSB3411: Could not load the Visual C++ component “VCBuild.exe”. If the component is not installed, eith
er 1) install the Microsoft Windows SDK for Windows Server 2008 and .NET Framework 3.5, or 2) install Microsoft Visual Studio 2008.
Done Building Project “BLAT01.proj” (Build target(s)) — FAILED.

Build FAILED.

“BLAT01.proj” (Build target) (1) ->
(Build target) ->
BLAT01.proj(37,5): error MSB3411: Could not load the Visual C++ component “VCBuild.exe”. If the component is not installed, ei
ther 1) install the Microsoft Windows SDK for Windows Server 2008 and .NET Framework 3.5, or 2) install Microsoft Visual Studio 2008.

0 Warning(s)
1 Error(s)

Time Elapsed 00:00:00.05

I do not see a problem with this version with x64…

I am using your tool LeakFinder from codeproject on Win32 and Win64.
It is working perefectly fine when run on Win32 and I am getting following output (as expected) :

######## CRT-Leaks ########
————— Key: 63, 32 bytes ———
d:\tempproj\leakfinder-rc5\main.cpp (44): main
f:\sp\vctools\crt_bld\self_x86\crt\src\crt0.c (327): __tmainCRTStartup
f:\sp\vctools\crt_bld\self_x86\crt\src\crt0.c (196): mainCRTStartup
7C817067 (kernel32): (filename not available): RegisterWaitForInputIdle
————— Key: 64, 10 bytes ———
d:\tempproj\leakfinder-rc5\main.cpp (18): Func5
d:\tempproj\leakfinder-rc5\main.cpp (23): Func4
d:\tempproj\leakfinder-rc5\main.cpp (27): Func3
d:\tempproj\leakfinder-rc5\main.cpp (31): Func2
d:\tempproj\leakfinder-rc5\main.cpp (35): Func1
d:\tempproj\leakfinder-rc5\main.cpp (47): main
f:\sp\vctools\crt_bld\self_x86\crt\src\crt0.c (327): __tmainCRTStartup
f:\sp\vctools\crt_bld\self_x86\crt\src\crt0.c (196): mainCRTStartup
7C817067 (kernel32): (filename not available): RegisterWaitForInputIdle
######## COM-Leaks ########
————— Key: 00178CA8, 999 bytes ———
775833D5 (ole32): (filename not available): CoRevokeMallocSpy
774FD073 (ole32): (filename not available): CoTaskMemAlloc
d:\tempproj\leakfinder-rc5\main.cpp (39): DoCoMalloc
d:\tempproj\leakfinder-rc5\main.cpp (46): main
f:\sp\vctools\crt_bld\self_x86\crt\src\crt0.c (327): __tmainCRTStartup
f:\sp\vctools\crt_bld\self_x86\crt\src\crt0.c (196): mainCRTStartup
7C817067 (kernel32): (filename not available): RegisterWaitForInputIdle
‘LeakFinder_VC5.exe’: Unloaded ‘C:\WINDOWS\system32\dbghelp.dll’
The program ‘[5256] LeakFinder_VC5.exe: Native’ has exited with code 0 (0×0).

However, when run on Win64 output is as under :

######## CRT-Leaks ########
————— Key: 65, 48 bytes ———
————— Key: 66, 10 bytes ———
######## COM-Leaks ########
————— Key: 000000000024A600, 999 bytes ———
f:\sp\vctools\crt_bld\self_64_amd64\crt\src\mlock.c (349): _lock
0000000140082670 (LeakFinder_VC5): (filename not available): `dynamic atexit destructor for ‘zzz_LeakFinder”
f:\sp\vctools\crt_bld\self_64_amd64\crt\src\crt0dat.c (553): doexit
f:\sp\vctools\crt_bld\self_64_amd64\crt\src\crt0dat.c (399): exit
f:\sp\vctools\crt_bld\self_64_amd64\crt\src\crt0.c (333): __tmainCRTStartup
f:\sp\vctools\crt_bld\self_64_amd64\crt\src\crt0.c (196): mainCRTStartup
000000007735F56D (kernel32): (filename not available): BaseThreadInitThunk
0000000077593281 (ntdll): (filename not available): RtlUserThreadStart
‘LeakFinder_VC5.exe’: Unloaded ‘C:\Windows\System32\dbghelp.dll’
The thread ‘Win64 Thread’ (0×964) has exited with code 0 (0×0).
The program ‘[3400] LeakFinder_VC5.exe: Native’ has exited with code 0 (0×0).
exited with code 0 (0×0).

On debugging on Win64 I found out that ShowCallstack() in StackWalker.cpp wouldn’t get enogh frames. I am not able to figure out what could be the reason.
Could you please provide some clue and let me know if you any further information from me. Also, if you could tell why Rbp in context on Win64 is coming out as 0.

Thanks in advance,
Deepak.