C / C++ / MFC

Bram van Kampen wrote:

The best way I can think of, is to get a separate machine with XpSp3 on it, and single step through it with a debugger. (you can also make your own system dual boot.) All you need is 'Bare Bones', with the Compiler, and your Files.

permutations wrote:

I'd like to do that, but I'm running out of computers to put test code on.

permutations wrote:

Do you know at what point in an MFC program the _tWinMain function is called?

permutations wrote:

I broke down and did it

permutations wrote:

I still cannot reproduce the bug, even under XP SP3. Also, two more beta testers turned up with XP SP3 and they can't, either

permutations wrote:

two more beta testers turned up with XP SP3 and they can't, either

Chris Losinger wrote:

2. are you loading any DLLs? are they doing anything non-trivial in their WinMain's ?

permutations wrote:

The crash is in the _tWinMain() procedure, and I don't know at what point that is called. Isn't it called before InitInstance() even executes?

extern "C" int WINAPI
_tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
	_In_ LPTSTR lpCmdLine, int nCmdShow)
#pragma warning(suppress: 4985)
{
	// call shared/exported WinMain
	return AfxWinMain(hInstance, hPrevInstance, lpCmdLine, nCmdShow);
}

Chris Losinger wrote:

tWinMain calls AfxWinMain (in fact, that's all it does, in the MFC source that comes with VS08 ), and AfxWinMain eventually ends up calling your app's InitInstance.

Chris Losinger wrote:

so, i doubt the problem is in tWinMain itself. the problem has to be farther down the line.

Chris Losinger wrote:

if you can't reproduce the problem on your own machine, you can try something like a map file[^]. or, there's always good old log files[^].

permutations wrote:

How can code farther down the line, that hasn't executed yet, be the cause of the crash?

permutations wrote:

I also cannot figure out why the program would be calling _tWinMain TWICE in different modules.

Chris Losinger wrote:

just a guess, but the tWinMain call might be the last-known function. that is, the crash blew most of the call stack away leaving tWinMain on top. that happens from time to time, even when running inside a debugger - a stray pointer kills your app and the debugger says it died inside AfxInitInstance (or whatever) - that's not the actual last function, it's just what the rubble looks like, after everything fell over.

Chris Losinger wrote:

i suspect a DLL could call tWinMain as part of its own startup.

permutations wrote:

the crash pops up inside the source file crt0c

Chris Losinger wrote:

couple of things to look for:

1. initialization of global variables (especially classes which do non-trivial things in their ctors).

2. are you loading any DLLs? are they doing anything non-trivial in their DllMain's (edited by Avi) ?

Chris Losinger wrote:

if you can't reproduce the problem on your own machine, you can try something like a map file[^]. or, there's always good old log files[^].

permutations wrote:

At least now I know for sure the error is in InitInstance(). I just don't know WHERE in InitInstance().

Chris Losinger wrote:

also, i ran into a similar problem when i apparently got a bit too aggressive with pre-compiled headers. i had moved everything i could think of into the PCH, and for some reason, this caused the ctor of a global std::list variable to explode on startup. i never could track down exactly why it was happening, so i simply turned off PCH for that configuration and it worked fine.