Release build.
-
I posted a message HERE a few days ago, but I have been unable to figure out a solution. I was hoping maybe you GURU's may have some helpful thoughts. The basic situation is as follows... I have SDI formview based app. It runs fine when compiled in debug mode, and compiles fine in release mode. However, the release version, crashes before reaching the first line of CMyApp::InitInstance() when I attempt to run it. Turning off optimizations doesn't help and I am out of ideas on what to try next. When I attempt to run to cursor on the first line of InitInstance, the debugger stops in "\Mfc\Src\Appmodul.cpp" on the following function.
extern "C" int WINAPI
_tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow)
{/* <---------------- IT STOPS HERE*/
// call shared/exported WinMain
return AfxWinMain(hInstance, hPrevInstance, lpCmdLine, nCmdShow);
}When I press I run after that it pops up "Unhandled exception in MyApp.exe: 0x0000005: Access Violation", and the debug window, after I stop debugging, shows "First-chance exception in LU.exe (KERNEL32.DLL): 0xC0000005: Access Violation." Any ideas, thoughts would be greatly appreciated. - John
-
I posted a message HERE a few days ago, but I have been unable to figure out a solution. I was hoping maybe you GURU's may have some helpful thoughts. The basic situation is as follows... I have SDI formview based app. It runs fine when compiled in debug mode, and compiles fine in release mode. However, the release version, crashes before reaching the first line of CMyApp::InitInstance() when I attempt to run it. Turning off optimizations doesn't help and I am out of ideas on what to try next. When I attempt to run to cursor on the first line of InitInstance, the debugger stops in "\Mfc\Src\Appmodul.cpp" on the following function.
extern "C" int WINAPI
_tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow)
{/* <---------------- IT STOPS HERE*/
// call shared/exported WinMain
return AfxWinMain(hInstance, hPrevInstance, lpCmdLine, nCmdShow);
}When I press I run after that it pops up "Unhandled exception in MyApp.exe: 0x0000005: Access Violation", and the debug window, after I stop debugging, shows "First-chance exception in LU.exe (KERNEL32.DLL): 0xC0000005: Access Violation." Any ideas, thoughts would be greatly appreciated. - John
Do you have any static objects in your program? Or, is there any code in CYourApp constructor? Tomasz Sowinski -- http://www.shooltz.com
-
I posted a message HERE a few days ago, but I have been unable to figure out a solution. I was hoping maybe you GURU's may have some helpful thoughts. The basic situation is as follows... I have SDI formview based app. It runs fine when compiled in debug mode, and compiles fine in release mode. However, the release version, crashes before reaching the first line of CMyApp::InitInstance() when I attempt to run it. Turning off optimizations doesn't help and I am out of ideas on what to try next. When I attempt to run to cursor on the first line of InitInstance, the debugger stops in "\Mfc\Src\Appmodul.cpp" on the following function.
extern "C" int WINAPI
_tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow)
{/* <---------------- IT STOPS HERE*/
// call shared/exported WinMain
return AfxWinMain(hInstance, hPrevInstance, lpCmdLine, nCmdShow);
}When I press I run after that it pops up "Unhandled exception in MyApp.exe: 0x0000005: Access Violation", and the debug window, after I stop debugging, shows "First-chance exception in LU.exe (KERNEL32.DLL): 0xC0000005: Access Violation." Any ideas, thoughts would be greatly appreciated. - John
Check wether release version of this app links all other libraries in release version. Furthermore - try to turn off incremental linking. I have one project which does not want to run (though this is the debug version which does not want to get up - release runs fine) if inremental linking is on...:confused:
-
I posted a message HERE a few days ago, but I have been unable to figure out a solution. I was hoping maybe you GURU's may have some helpful thoughts. The basic situation is as follows... I have SDI formview based app. It runs fine when compiled in debug mode, and compiles fine in release mode. However, the release version, crashes before reaching the first line of CMyApp::InitInstance() when I attempt to run it. Turning off optimizations doesn't help and I am out of ideas on what to try next. When I attempt to run to cursor on the first line of InitInstance, the debugger stops in "\Mfc\Src\Appmodul.cpp" on the following function.
extern "C" int WINAPI
_tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow)
{/* <---------------- IT STOPS HERE*/
// call shared/exported WinMain
return AfxWinMain(hInstance, hPrevInstance, lpCmdLine, nCmdShow);
}When I press I run after that it pops up "Unhandled exception in MyApp.exe: 0x0000005: Access Violation", and the debug window, after I stop debugging, shows "First-chance exception in LU.exe (KERNEL32.DLL): 0xC0000005: Access Violation." Any ideas, thoughts would be greatly appreciated. - John
Mukkie might have a point - plus you are running a unicode based app... The only KERNEL32 routine that I can see if I break where you indicate is in BaseProcessStart@4. Since a DLL I'm implictly linking to loads before I hit _tWinMain, I'm starting to suspect a DLL. Hmmm... maybe its an errant MFC dll - try a static link to mfc? I saw a situation once where an install left MFC dlls in the system dir on NT - hiding the proper ones that were in system32.
-
Do you have any static objects in your program? Or, is there any code in CYourApp constructor? Tomasz Sowinski -- http://www.shooltz.com
No code in the constructor.
-
I posted a message HERE a few days ago, but I have been unable to figure out a solution. I was hoping maybe you GURU's may have some helpful thoughts. The basic situation is as follows... I have SDI formview based app. It runs fine when compiled in debug mode, and compiles fine in release mode. However, the release version, crashes before reaching the first line of CMyApp::InitInstance() when I attempt to run it. Turning off optimizations doesn't help and I am out of ideas on what to try next. When I attempt to run to cursor on the first line of InitInstance, the debugger stops in "\Mfc\Src\Appmodul.cpp" on the following function.
extern "C" int WINAPI
_tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow)
{/* <---------------- IT STOPS HERE*/
// call shared/exported WinMain
return AfxWinMain(hInstance, hPrevInstance, lpCmdLine, nCmdShow);
}When I press I run after that it pops up "Unhandled exception in MyApp.exe: 0x0000005: Access Violation", and the debug window, after I stop debugging, shows "First-chance exception in LU.exe (KERNEL32.DLL): 0xC0000005: Access Violation." Any ideas, thoughts would be greatly appreciated. - John
Ok, here's the latest. By the suggestion from someone on the previous thread, I started throwing 5 bazillion message boxes everywhere, ie AfxMessageBox("POSITION 1") to see where I was REALLY getting. It turns out debugging the release version doesn't work to well because you can't go line by line. And I found that I crash when ParseCommandLine(cmdInfo); is called from InitInstance(). I found using the debug version, that the MainFrame constructor is called from somewhere within the calls in ParseCommandLine(). So, I assumed I had some variable initialization problem. I initialized every single variable in the constructor, but that didn't seem to help.
-
Ok, here's the latest. By the suggestion from someone on the previous thread, I started throwing 5 bazillion message boxes everywhere, ie AfxMessageBox("POSITION 1") to see where I was REALLY getting. It turns out debugging the release version doesn't work to well because you can't go line by line. And I found that I crash when ParseCommandLine(cmdInfo); is called from InitInstance(). I found using the debug version, that the MainFrame constructor is called from somewhere within the calls in ParseCommandLine(). So, I assumed I had some variable initialization problem. I initialized every single variable in the constructor, but that didn't seem to help.
It turns out debugging the release version doesn't work to well because you can't go line by line Do you enable debug info in the release build? On the C++ tab, general category, select program database for debug info. On the link tab, select generate debug info - you should be able to start with F10 and step through your code...
-
It turns out debugging the release version doesn't work to well because you can't go line by line Do you enable debug info in the release build? On the C++ tab, general category, select program database for debug info. On the link tab, select generate debug info - you should be able to start with F10 and step through your code...
Ahh, thanks, I didn't have the program database selected. The error occurs on the call "ProcessShellCommand(cmdInfo)"
-
Check wether release version of this app links all other libraries in release version. Furthermore - try to turn off incremental linking. I have one project which does not want to run (though this is the debug version which does not want to get up - release runs fine) if inremental linking is on...:confused:
All libraries are linked. I tried both using mfc in both a static and shared dll. I tried with and without incremental linking. Still broke. I seem to crash on "ProcessShellCommand(cmdInfo)".
-
Mukkie might have a point - plus you are running a unicode based app... The only KERNEL32 routine that I can see if I break where you indicate is in BaseProcessStart@4. Since a DLL I'm implictly linking to loads before I hit _tWinMain, I'm starting to suspect a DLL. Hmmm... maybe its an errant MFC dll - try a static link to mfc? I saw a situation once where an install left MFC dlls in the system dir on NT - hiding the proper ones that were in system32.
How do you tell what is a KERNEL32 routine? And what within "ProcessShellCommand(cmdInfo)" calls routines within KERNAL32?
-
Ahh, thanks, I didn't have the program database selected. The error occurs on the call "ProcessShellCommand(cmdInfo)"
Are you passing any parameters to the program with the Debug project settings dialog? Perhaps different for the release than those passed for the debug build? Remember, you can't use fileNothing in an SDI app. Another thing to watch for (you'll kick yourself) is surrounding code with ASSERT statements - the code just disappears in release, and if its necessary code... BA-BOOM! Hmmm... maybe you could post your InitInstance code?
-
Are you passing any parameters to the program with the Debug project settings dialog? Perhaps different for the release than those passed for the debug build? Remember, you can't use fileNothing in an SDI app. Another thing to watch for (you'll kick yourself) is surrounding code with ASSERT statements - the code just disappears in release, and if its necessary code... BA-BOOM! Hmmm... maybe you could post your InitInstance code?
Found solution....or fix anyway. I believe there is something funny with ON_CONTROL_RANGE message mapping when it is involved with a dialog bar, and a formview app. If I don't use the ON_CONTROL_RANGE message handling, it works fine, so I found a way around it. I had to comment out all my message handlers one by one (well really 50% at a time to narrow it down...etc) to find out where my error occured. I guess that when you call m_wndMyDialogBar.Create(blah blah blah) it creates each of the controls, and then if you have radio buttons like I did, it sets their check value to 0. Thus, it would call the OnCheckMyCoolRadioButton message handler, and it would crash AFTER executing this handler and attempting to return. If you make seperate message handlers for each button, ie ON_BN_CLICKED instead of ON_CONTROL_RANGE, then it works fine. Finally, DONE!
-
Found solution....or fix anyway. I believe there is something funny with ON_CONTROL_RANGE message mapping when it is involved with a dialog bar, and a formview app. If I don't use the ON_CONTROL_RANGE message handling, it works fine, so I found a way around it. I had to comment out all my message handlers one by one (well really 50% at a time to narrow it down...etc) to find out where my error occured. I guess that when you call m_wndMyDialogBar.Create(blah blah blah) it creates each of the controls, and then if you have radio buttons like I did, it sets their check value to 0. Thus, it would call the OnCheckMyCoolRadioButton message handler, and it would crash AFTER executing this handler and attempting to return. If you make seperate message handlers for each button, ie ON_BN_CLICKED instead of ON_CONTROL_RANGE, then it works fine. Finally, DONE!
Good stuff - one for the books. Those macros are notorious for introducing 'works in debug but not in release' woes - even without going for ON_CONTROL_RANGE. I noticed that VC7 is much better about catching mismatched fn sigs etc associated with these - actually, its much better at dealing with macros period. Suggest you ferret away a snapshot of the problem as it was, and compile with VC7 when you get a chance. Ain't debugging fun, tho? :)