Release mode crashes, debug mode doesn't (and it's not my code)
-
Arg. Someone please help because this is driving my crazy! I have several apps that when I compile them using the win32 release configuration they bomb immediately. I'm downloading SP5 now, and I'm wondering if that will fix it. I've seen this before, and so have other devlopers where I work, but they all fixed it by shipping debug code. Unfortuately, that is not acceptible for the product. If I can't compile it as release, is there a way to use the debug version, but instead of having the ASSERTS() in the MFC stuff produce a message box, have it bomb or exit right away? (Which would make it acceptible) Many thanks in advance! PS. I know it's not my code because according to the stack, it hasn't even entered my code yet: MFC42! 73ddb4ec() KERNEL32! 77e7eb69()
Jason Hihn wrote: PS. I know it's not my code because according to the stack, it hasn't even entered my code yet: MFC42! 73ddb4ec() KERNEL32! 77e7eb69() The fact that you're not on the call stack doesn't get you off the hook. E.G. It could be accessing memory that you released, trying to access a non zero terminated string, or an unavailable resource (ID defined but the actual resource has been deleted) Debug mode has a lot of safeguards, can have different aligment (different code/object size) and can cause eg an extra int to be available in an array without overwriting data while release build overwrites essential data so someone should fix the code :) You can turn of the debug asserts by undefing _DEBUG, remove it from the project settings c/c++ preprocessor defines (I think this will however also cause linking to the release MFC dll's) Better yet would be to identify the asserts and prevent them from happening (check it yourself first and then bomb or grace shutdown) Good Luck Rutger
-
I am pretty sure it is your code :). It doesn't have to enter your code to be your mistake. Maybe you are playing with some window handles and it will crash into a mfc code, not yours. Have a look at this article, maybe you can find why it crashes. Also you may try to include some debug information in the release mode and step into code to see what is causing the assert. Providing some code will be very helpful. Best regards, Alexandru Savescu
Well, adding to the complexity is the fact that it's an NT service, so it has no main() to speak of. It has an init() and a run() and a stop(). I put very simple MessageBox(NULL, "Running", "NT Service", MB_OK) statements at the very beginning of those and it dies before even hitting them. What's making it even harder is then ir crashes, that's all thr stak info I have. If it's in my code, I can look at my map file an find what function did it, but I don't have map files ofr MCF42.dll!
-
Arg. Someone please help because this is driving my crazy! I have several apps that when I compile them using the win32 release configuration they bomb immediately. I'm downloading SP5 now, and I'm wondering if that will fix it. I've seen this before, and so have other devlopers where I work, but they all fixed it by shipping debug code. Unfortuately, that is not acceptible for the product. If I can't compile it as release, is there a way to use the debug version, but instead of having the ASSERTS() in the MFC stuff produce a message box, have it bomb or exit right away? (Which would make it acceptible) Many thanks in advance! PS. I know it's not my code because according to the stack, it hasn't even entered my code yet: MFC42! 73ddb4ec() KERNEL32! 77e7eb69()
The bounds chekers help me several times in that problem.... one solution is use the dr watson... Compiles your code with mapfile, look into the file that leave the Dr watson, and llok for in the map file generated... This can help you... Carlos Antollini. Sonork ID 100.10529 cantollini
-
Arg. Someone please help because this is driving my crazy! I have several apps that when I compile them using the win32 release configuration they bomb immediately. I'm downloading SP5 now, and I'm wondering if that will fix it. I've seen this before, and so have other devlopers where I work, but they all fixed it by shipping debug code. Unfortuately, that is not acceptible for the product. If I can't compile it as release, is there a way to use the debug version, but instead of having the ASSERTS() in the MFC stuff produce a message box, have it bomb or exit right away? (Which would make it acceptible) Many thanks in advance! PS. I know it's not my code because according to the stack, it hasn't even entered my code yet: MFC42! 73ddb4ec() KERNEL32! 77e7eb69()
Jason - I wish you well my friend. You are about to embark on a painful but eventful journey. My best wishes are with you. I think u can be assured that the bug is in your code. Sorry I sound like that, but I have been through the hard knocks of debugging a major bug in the release build. I hope you dont have complier optimizations turned on, because then even Dr Watson will confound you. Turn compiler optimizations off and see if you can reproduce the problem. You can turn it back on after finding the bug. The book "Debugging Windows Applications" (MIke Wooding and Everett Mc Kay) was of immemse use to me. This is where tools like BoundsChecker will prove to be invaluable. The reward : After you hunt down the bug, you can go out and have a beer. That will be the best beer u ever had. - Vivek
-
Jason - I wish you well my friend. You are about to embark on a painful but eventful journey. My best wishes are with you. I think u can be assured that the bug is in your code. Sorry I sound like that, but I have been through the hard knocks of debugging a major bug in the release build. I hope you dont have complier optimizations turned on, because then even Dr Watson will confound you. Turn compiler optimizations off and see if you can reproduce the problem. You can turn it back on after finding the bug. The book "Debugging Windows Applications" (MIke Wooding and Everett Mc Kay) was of immemse use to me. This is where tools like BoundsChecker will prove to be invaluable. The reward : After you hunt down the bug, you can go out and have a beer. That will be the best beer u ever had. - Vivek
same thing happened to me before, it is problem of libraries used. did you use database in your apps? please post a little bit more info: i.e. com, dcom, etc. includeh10
-
Arg. Someone please help because this is driving my crazy! I have several apps that when I compile them using the win32 release configuration they bomb immediately. I'm downloading SP5 now, and I'm wondering if that will fix it. I've seen this before, and so have other devlopers where I work, but they all fixed it by shipping debug code. Unfortuately, that is not acceptible for the product. If I can't compile it as release, is there a way to use the debug version, but instead of having the ASSERTS() in the MFC stuff produce a message box, have it bomb or exit right away? (Which would make it acceptible) Many thanks in advance! PS. I know it's not my code because according to the stack, it hasn't even entered my code yet: MFC42! 73ddb4ec() KERNEL32! 77e7eb69()
Well I've done some investigating... Looks like it does actually run my code, but only the constructors run. Those are filled with bounds checked string copies and integer initializations. All contructors return ok. Where the problem lies is when it tries to call StartService() which then goes to ServiceMain(), then to Initialize(). Somehow on it's way to calling StartService, it is bombing. The thing is I can't figure out what is begin called between the constuctors and StartService. Arg! PS. It's just a win32 app with sockets (NOT MFC! I'm using wrappers from W3MFC) and a MySQL library.
-
Arg. Someone please help because this is driving my crazy! I have several apps that when I compile them using the win32 release configuration they bomb immediately. I'm downloading SP5 now, and I'm wondering if that will fix it. I've seen this before, and so have other devlopers where I work, but they all fixed it by shipping debug code. Unfortuately, that is not acceptible for the product. If I can't compile it as release, is there a way to use the debug version, but instead of having the ASSERTS() in the MFC stuff produce a message box, have it bomb or exit right away? (Which would make it acceptible) Many thanks in advance! PS. I know it's not my code because according to the stack, it hasn't even entered my code yet: MFC42! 73ddb4ec() KERNEL32! 77e7eb69()
When you switch from debig to release mode, rather than inherit settings from the debug mode, (even such no brainers as /subsystem:XXXXXXX) it starts from some dumb defaults which can have nothing do to with your debug mode program. I had to change from /subsystem:windows to /subsystem console. The really weird thing (and for this I blame Microsoft) is that I had no WinMain(), only a main(). With /subsystem:windows I should have gotten a warning at the least. Now, even so, I'd expect my program to crash (or nto even compile) because there was no WinMain, BUT SOME HOW ONE GOT SUPPLIED TO IT. I accidentaly I ran it on my PC (remember it's a service, it's supposed to be started that way, plus I'm running Win98, which doesn't have full NT-Services) and it put me into a WinMain. Where I came from, I don't know... then I remembered to check the subsystem. Many thanks to all you who tried to help!
-
Well, adding to the complexity is the fact that it's an NT service, so it has no main() to speak of. It has an init() and a run() and a stop(). I put very simple MessageBox(NULL, "Running", "NT Service", MB_OK) statements at the very beginning of those and it dies before even hitting them. What's making it even harder is then ir crashes, that's all thr stak info I have. If it's in my code, I can look at my map file an find what function did it, but I don't have map files ofr MCF42.dll!
Jason Hihn wrote: I put very simple MessageBox(NULL, "Running", "NT Service", MB_OK) statements at the very beginning of those and it dies before even hitting them. MessageBox ? In a service ? It may not appear. Well, try LogEvent and see the event viewer... Concussus surgo. When struck I rise.
-
When you switch from debig to release mode, rather than inherit settings from the debug mode, (even such no brainers as /subsystem:XXXXXXX) it starts from some dumb defaults which can have nothing do to with your debug mode program. I had to change from /subsystem:windows to /subsystem console. The really weird thing (and for this I blame Microsoft) is that I had no WinMain(), only a main(). With /subsystem:windows I should have gotten a warning at the least. Now, even so, I'd expect my program to crash (or nto even compile) because there was no WinMain, BUT SOME HOW ONE GOT SUPPLIED TO IT. I accidentaly I ran it on my PC (remember it's a service, it's supposed to be started that way, plus I'm running Win98, which doesn't have full NT-Services) and it put me into a WinMain. Where I came from, I don't know... then I remembered to check the subsystem. Many thanks to all you who tried to help!
Jason Hihn wrote: because there was no WinMain, BUT SOME HOW ONE GOT SUPPLIED TO IT MFC supplies one. Are you using MFC ? Concussus surgo. When struck I rise.
-
When you switch from debig to release mode, rather than inherit settings from the debug mode, (even such no brainers as /subsystem:XXXXXXX) it starts from some dumb defaults which can have nothing do to with your debug mode program. I had to change from /subsystem:windows to /subsystem console. The really weird thing (and for this I blame Microsoft) is that I had no WinMain(), only a main(). With /subsystem:windows I should have gotten a warning at the least. Now, even so, I'd expect my program to crash (or nto even compile) because there was no WinMain, BUT SOME HOW ONE GOT SUPPLIED TO IT. I accidentaly I ran it on my PC (remember it's a service, it's supposed to be started that way, plus I'm running Win98, which doesn't have full NT-Services) and it put me into a WinMain. Where I came from, I don't know... then I remembered to check the subsystem. Many thanks to all you who tried to help!
Jason Hihn wrote: BUT SOME HOW ONE GOT SUPPLIED TO IT. I accidentaly I ran it on my PC (remember it's a service, it's supposed to be started that way, plus I'm running Win98, which doesn't have full NT-Services) and it put me into a WinMain. Where I came from, I don't know... then I remembered to check the subsystem. AFAIS from your original post, your app is linked against MFC42.dll. Are you sure you are not using MFC? I only ask, because it sound quite suitable to me, that MFC42.dll contains your "mysterious WinMain()". -- Daniel Lohmann http://www.losoft.de