crash in _tWinMain, crt0.c, XP SP3 only - HELP!!
-
permutations wrote:
How can code farther down the line, that hasn't executed yet, be the cause of the crash?
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. just a guess, though.
permutations wrote:
I also cannot figure out why the program would be calling _tWinMain TWICE in different modules.
i suspect a DLL could call tWinMain as part of its own startup.
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.
Very interesting! I suspect you are right. I didn't think of that.
Chris Losinger wrote:
i suspect a DLL could call tWinMain as part of its own startup.
Also interesting, and I think you may be right there, too. I'd better get going on installing XP SP3 and a compiler somewhere so I can reproduce the bug here. So tedious. Maybe I'll watch TV while I do that.
-
You are assuming I'm able to reproduce the fault on my own system. Sadly, no. It is only this one particular beta tester who is experiencing the crash. The program runs fine on all my own computers (three different versions of Windows), and on every other person's computer who has ever run it. The only thing I have to go on is the crash dump this particular beta tester sends me each time I send him a new build. I think I have to bite the bullet and install the operating system he's using on one of my own systems. I can't see how I can possibly find this any other way, given that /MAPINFO:LINES is no longer supported by the linker in Visual Studio 2008. I'll shut down my XP SP2 computer, pull out the hard drive and put in another hard drive I have that I don't mind blowing away, and install XP SP3 and VC++ 6 (which blessedly supports /MAPINFO:LINES. I just pray that I am able to reproduce the bug this way. I can't think what else it could be besides the unique platform he's using. I don't think any of my other beta testers are running XP SP3.
Good luck. I think that you are right about reproducing the error so that you can identify it. Will the VC 6 debugger be compatible with your VS 2008 executable?
Please do not read this signature.
-
Good luck. I think that you are right about reproducing the error so that you can identify it. Will the VC 6 debugger be compatible with your VS 2008 executable?
Please do not read this signature.
It was originally written with VC++ 6 so it should work fine. However I am freaking out because I can't find the VC++ 6 disk, and it's not on the MSDN site for some reason. They have VC++ 4.2 and then Visual Studio 2005. I don't know why they don't have VC++ 6. Does it go by some other name? I can't remember. EDIT: OMG it's gone - I can't believe it. I feel like going to the storage place to look through my old MSDN disks for it, but it's night and raining. I can't believe this. http://blogs.msdn.com/publicsector/archive/2005/12/07/501169.aspx
modified on Friday, March 12, 2010 9:18 PM
-
It was originally written with VC++ 6 so it should work fine. However I am freaking out because I can't find the VC++ 6 disk, and it's not on the MSDN site for some reason. They have VC++ 4.2 and then Visual Studio 2005. I don't know why they don't have VC++ 6. Does it go by some other name? I can't remember. EDIT: OMG it's gone - I can't believe it. I feel like going to the storage place to look through my old MSDN disks for it, but it's night and raining. I can't believe this. http://blogs.msdn.com/publicsector/archive/2005/12/07/501169.aspx
modified on Friday, March 12, 2010 9:18 PM
Got it - PHEW!! That's a relief. Saved again by my packrat instinct. I had it in storage. Now to set up the hard drive...
-
I have a problem in my program that I don't know how to even begin to track down. Please help! It's an MFC program compiled in Visual Studio 2008 for WinXP and above (WinVer=0x0501). It runs fine for everyone who has tested it except one person who is running WinXP SP3. He's tried it on two different computers running WinXP SP3 and it crashes on both. I'm pretty sure he's the only one with SP3. I have XP SP2 here and it runs fine. It crashes at the Windows entry point - the call to _tWinMain in crt0.c (which I know through the crash.dmp file he sent me):
mainret = _tWinMain( (HINSTANCE)&__ImageBase, NULL, lpszCommandLine, StartupInfo.dwFlags & STARTF_USESHOWWINDOW ? StartupInfo.wShowWindow : SW_SHOWDEFAULT );The error message says: "Unhandled exception at 0x0041505e (myprog.exe) in CRASH.DMP: 0xC0000005: Access violation reading location 0x00000004." I don't know how to even begin to track down a problem like this, especially when it appears to be platform-specific. Could someone give me some guidance on how to go about this? Thanks!!!!I've got XP SP3 installed and I can't reproduce the crash. The program runs fine. I also found someone else with XP SP3 and it didn't crash for him, either. There is apparently something unique about how this one beta tester sets up his systems (the crash happens on both his computers), but I have no idea what. On the plus side, I'm installing VC++ 6 on the XP SP3 system and that has an option for map line numbers. I'll move the project over to that computer and rebuild. Then when I get the crash report back I'll know exactly what line is causing the problem.
-
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.
I'd like to do that, but I'm running out of computers to put test code on. I used to have two XP notebooks, but one of them is dying - it makes a very loud grinding noise - and none of my machines has the hard disk space for dual booting. Do you know at what point in an MFC program the _tWinMain function is called? If I could know how much of my code is executed - at what point in my program the deadly call is made - it would be a huge help. I'm just not that adept with the more exotic aspects of the debugger so I don't know how to figure this out.
Hi,
permutations wrote:
I'd like to do that, but I'm running out of computers to put test code on.
well, That's somewhat essential if you support code spanning different O'S'. I have a dedicated Desktop machine with several harddisks, which I can boot up on anything from Xp Standard to Win7. The machine cost me less than £100 in a carboot sale. It 'Runs' vista, but just about. (a Lot happier with Win7). It is not ideal as a recommended environment for a customer, but it does exactly do the things I want to trap, i.e. incompatibilities.
permutations wrote:
Do you know at what point in an MFC program the _tWinMain function is called?
Just start debugging by pressing F10. The program will break at _tWinMain. Then in your Stack window, go to the Calling Routine, and scroll to the top where you find _WinMainCRTStartUp(). Set a breakpoint there, and start again. That code will call set up the libraries and call the constructors. :)
Bram van Kampen
-
Hi,
permutations wrote:
I'd like to do that, but I'm running out of computers to put test code on.
well, That's somewhat essential if you support code spanning different O'S'. I have a dedicated Desktop machine with several harddisks, which I can boot up on anything from Xp Standard to Win7. The machine cost me less than £100 in a carboot sale. It 'Runs' vista, but just about. (a Lot happier with Win7). It is not ideal as a recommended environment for a customer, but it does exactly do the things I want to trap, i.e. incompatibilities.
permutations wrote:
Do you know at what point in an MFC program the _tWinMain function is called?
Just start debugging by pressing F10. The program will break at _tWinMain. Then in your Stack window, go to the Calling Routine, and scroll to the top where you find _WinMainCRTStartUp(). Set a breakpoint there, and start again. That code will call set up the libraries and call the constructors. :)
Bram van Kampen
I broke down and did it. I don't have a lot of computers, but I do have a lot of spare hard drives, it turns out. I forgot about that. 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. I think it's something this other guy is running. I asked him to try disabling his startup programs. It may be a bug in something else he's running that's writing beyond the boundaries of its own memory. Also, I have VC++ 6 installed now on the XP SP3 system, and I'm going to rebuild the project there with line numbers in the map file. That will tell me exactly the line that is causing the problem.
-
I broke down and did it. I don't have a lot of computers, but I do have a lot of spare hard drives, it turns out. I forgot about that. 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. I think it's something this other guy is running. I asked him to try disabling his startup programs. It may be a bug in something else he's running that's writing beyond the boundaries of its own memory. Also, I have VC++ 6 installed now on the XP SP3 system, and I'm going to rebuild the project there with line numbers in the map file. That will tell me exactly the line that is causing the problem.
Hi
permutations wrote:
I broke down and did it
It's not that serious I hope... :omg:
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
Bugs like that can be tricky to find. An added problem is that seems to occur before WinMain starts. Things like Dumpfiles probably won't work! Things to look out for are your global variables. Are they all propperly initialised! If not, your program may work most of the time because the variable has a value that is by coincidence acceptable (or at least does not cause a crash). Change Something, (anything at all), and Oops! Crash!.
permutations wrote:
two more beta testers turned up with XP SP3 and they can't, either
That seems to be a good omen! Success, :)
Bram van Kampen
-
I've got XP SP3 installed and I can't reproduce the crash. The program runs fine. I also found someone else with XP SP3 and it didn't crash for him, either. There is apparently something unique about how this one beta tester sets up his systems (the crash happens on both his computers), but I have no idea what. On the plus side, I'm installing VC++ 6 on the XP SP3 system and that has an option for map line numbers. I'll move the project over to that computer and rebuild. Then when I get the crash report back I'll know exactly what line is causing the problem.
Actually, I think I did finally reproduce the crash, though in a slightly different form. Using VC++ 6 on XP SP3, when I do a full rebuild, I get a link error at the very end: "fatal error LNK 1561: entry point must be defined". If I then do an incremental build it links fine and I'm able to run the program. But this link error sounds suspiciously like the error my beta tester gets. When he runs the program, it fails on the program entry call to _tWinMain, and it's a read error. It's probably trying to read the program entry point and finding a null pointer. I think that if I'm able to solve my link problem, I'll also solve the beta tester's crash problem. It's probably one of two things: either I set up my DLL incorrectly and that is causing confusion about entry points (I can't even remember how I did this - I'm going over it all again), or (more likely) I have a buffer overrun in one of the very first variables I set up in the program that is wiping out the program entry point. Buffer overruns are always such a joy to hunt for (not).
-
Actually, I think I did finally reproduce the crash, though in a slightly different form. Using VC++ 6 on XP SP3, when I do a full rebuild, I get a link error at the very end: "fatal error LNK 1561: entry point must be defined". If I then do an incremental build it links fine and I'm able to run the program. But this link error sounds suspiciously like the error my beta tester gets. When he runs the program, it fails on the program entry call to _tWinMain, and it's a read error. It's probably trying to read the program entry point and finding a null pointer. I think that if I'm able to solve my link problem, I'll also solve the beta tester's crash problem. It's probably one of two things: either I set up my DLL incorrectly and that is causing confusion about entry points (I can't even remember how I did this - I'm going over it all again), or (more likely) I have a buffer overrun in one of the very first variables I set up in the program that is wiping out the program entry point. Buffer overruns are always such a joy to hunt for (not).
I'm stuck. I'm only getting this link error in Release mode. In Debug mode it's fine. And I've gone over everything carefully and can see no problems. I've also included error checking everywhere.