Weird error during programme startup

[Andrew Lowe]

Hi all,
I managed to draw the short straw at work and ended up doing the
twin conversion of ANSI to Unicode and VC++ 6 to VC++ 8. I've finally
gone right through the code and _T("...")'d everywhere, moved stuff into
string tables and so on. I've finally managed to get the whole app to
compile and link and run. Well sort of run. Before the splash screen
appears I get a "standard" error dialogue with the following:

------------------------

Microsoft Visual C++ Debug Library

Debug Assertion Failed
Program: My programme.exe
File: f:\rtm\vctools\vc7libs\ship\atlmfc\include\afxwin1.inl
Line: 24

Blah
Blah

Abort Retry Ignore

------------------------

I managed to get to the call stack and eventually traced this down
to a problem in _initterm() which is in crt0dat.c - MS code that I have
NO IDEA as to what's going on in. As an aside, I've now rebuilt this app
in release mode and the problem no longer exists, but I still need it to
work in debug for obvious reasons. Does anyone have any idea as to what's
going wrong here. I've stepped through the innards of _initterm and it
appears to be doing a whole lot of initialisation - other than that, I'm
stuffed as to whether I can work out what's going on - and wrong.

If anyone has any thoughts on what's going wrong and causing this
dialogue to pop up, it would be greatly appreciated if they could share
the knowledge.

Regards,
Andrew Lowe

p.s. I don't know why the error message says ...\VC71libs\.... I don't
even have VC7.1 on my machine.

p.p.s. This is running on XP using Visual Studio 2005.

[Alex Blekhman]

`_initterm' function calls constructors for all static
objects in a module. I opened "afxwin1.inl" on my machine
and it contains following ASSERT at line 24:

23 _AFXWIN_INLINE HINSTANCE AFXAPI AfxGetResourceHandle()
24 { ASSERT(afxCurrentResourceHandle != NULL); <--
Assert!
25 return afxCurrentResourceHandle; }

Obviously, it won't assert in release builds. You said that
you moved all strings to string tables. Can it be the case
that some global object tries to access resources from its
contructor before all necessary initializations are done?

Alex

[Andrew Lowe]

Alex,
You're a dead set legend. In the process of moving stuff into string
lists, I had moved some static registry strings. These don't need to be
translated hence should not have been moved. Moved them back from the
string table into the source code and everything now works - that is up
until the next bug I've got to work out :)

Once again, thanks for the lead,

Andrew

"Alex Blekhman" <xf...@oohay.moc> wrote in news:e$Q7wArGHHA.4712
@TK2MSFTNGP04.phx.gbl:

> "Andrew Lowe" wrote:
>> I managed to draw the short straw at work and ended up
>> doing the

[snip]
...
...
[snip]