Release won't run

[markus]

(Please excuse me for not really knowing where to post this.
I picked the biggest and best audience I know of.)

I am having trouble running my release build from VC7.
It doesn't. When started, it just shows a message box about failing to
initialize app + hex address + OK button to close it down.

The debug build runs fine as does a test MDI app from
VC++ project wizards (both release and debug).

Hence I think it's not the code or VC7 setup that fails me.
It must be my system with my app. I did get a blue
screen of death a while ago when building my app but
that does not explain why anything else built works ok.
I have tried "Rebuild Solution" with no luck.

What would you try next?

A dll issue?

TIA,

Markus

 

[Peter Dedrie]

Hey,

Are you linking your resources with a dll? I had A problem witch was
quit similar to yours. We compile our resources in a dll and then we
link it to our main program. Problem is that when you compile your
resources in debug mode and your program in release you're program
won't start.

When you are using VS7 you can set a breakpoint(or use a message box)
in the function InitInstance(). If he comes there, go step by step thru
your program and see where it generates the fault. Most of my release
problems or due to variables I forgot to initiate.

In the hope it helps you
Peter

 

[markus]

It never reaches InitInstance() of my CWinApp derived class.
It fails before that. Also, other members of our team are able
to build and run the same code in release mode so I don't
think it is a linking issue either (not that I know what linking
resources with a dll even means. Don't think we do that.)

Markus

 

[Andy Tang]

When you are using VS7 you can set a breakpoint(or use a message box)
in the function InitInstance(). If he comes there, go step by step thru
your program and see where it generates the fault. Most of my release
problems or due to variables I forgot to initiate.

That is true. Wierdly enough, Debug mode actually manages your memory
better so many memory problems won't actually be detected until you run
it in Release mode.

A

 

[Jonathan Wood]

Personally, I would start inserting a bunch of MessageBox calls, isolate
exactly where the error is happening, and then start printing the value of
various variables and error codes.

It would obviously be much easier if you could do this in Debug mode, but
you should eventually be able to obtain all the info you need.

 

[markus]

Like said, I can't do this because it won't
reach InitInstance() even.

 

[Jonathan Wood]

Sorry, I didn't appreciate what you were saying there.

 

[markus]

A sample call stack is as follows: from bottom to top


MFC71.dll!ATL::CSimpleStringT<wchar_t,1>::CSimpleStringT<wchar_t,1>(ATL::IAt
lStringMgr * pStringMgr=0x7c220064) Line 213 + 0x6 C++

::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > >(const char

* pszSrc=0x0046d891) Line 831 C++
myown.exe!$E1() Line 811 + 0x10 C++
msvcr71.dll!_initterm(void (void)* * pfbegin=0x00498000, void (void)* *
pfend=0x004980a8) Line 600 C
myown.exe!WinMainCRTStartup() Line 336 + 0xf C
KERNEL32.DLL!79551af6()

I get that and

"Unhandled exception at 0x7c16a575 (MFC71.dll) in myown.exe: 0xC0000005:
Access violation reading location 0x0000000c."

when trying to debug the release build. It's all chinese to me.

Markus

 

[Alexander Grigoriev]

Do you have global objects, such as CString, or CString in another global
object?

 

[markus]

Also, the exact error message I get is

The application failed to initialize properly (0xc0000005). Click on OK to
terminate the application.

 

[markus]

Yes, I think. I have

CString CMyClass::m_strMyCString = "";// initialize the static variable

at the end of one cpp file.

That's where it breaks the second time after an unhandled exception.
The first time it breaks has no source code available.