crash in _tWinMain, crt0.c, XP SP3 only - HELP!!
-
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.