Dear Members, Can anyone give me code in vc++ that should cause to stop the program with the error "Microsoft VC++ Runtime Library, Runtime Error! abnormal program termination"
Printable View
Dear Members, Can anyone give me code in vc++ that should cause to stop the program with the error "Microsoft VC++ Runtime Library, Runtime Error! abnormal program termination"
Your program crashes. You need to find the bug and fix it.
According to this KB code itself may by any code that worked before installing "Office XP or an Office XP program". :cool:Quote:
Originally Posted by wodin
So, if you really needed some help to solve this problem you should provide more info and also look at similar discussions:
https://www.google.com/search?hl=en&....0.mh2oPm7HkFo
Quote:
Originally Posted by Skizmo
Hi,
I want to simulate or reproduce this error by some code, that is what I need.
Why do you want it?Quote:
Originally Posted by wodin
Why do you need it? :confused:
Dear Victor,Quote:
Originally Posted by VictorN
In a previous post you had reommended to use ProcessExplorer to troubleshoot this error when it occurs. i have downloaded processexplorer and i want to test "how processexplorer can be used to solve this problem"
Well, I didn't mention ProcessExplorer in my previous post.Quote:
Originally Posted by wodin
However, if you meant thread, not post, then yes, I recommended to use it in your previous thread just to control the resources (like handles, GDI objects, User objects and so on) to be sure they all are properly closed/released so you don't have any resources leaks. Or, otherwise, you do have some leaks.
The same - about using memory: is it not permanently grows?
That's all I meant.
Dear Victor,Quote:
Originally Posted by VictorN
yes,you are right, you suggested processexplorer in my previous thread only. please help in my current question also on simulating exactly this error in a test code
Sorry, but I won't. I don't see any sense in such type of simulation. Instaed you have to find out the real reason of your problem.
BTW, did you see an address of crash? Sometimes you could see it in event viewer...
Did you observe some resource or memory growing used by your application since the last week?
we didnt find anything in event viewer also at the time of crash. ours is a trading software it is started and stopped on daily basis. this error comes very rarely, out of 4 years of operations only 4 times it has occured. when will it happen again? we dont know but our client wants to fix this immediately.Quote:
Originally Posted by VictorN
If your code has an abnormal termination bug, you won't get any insight into the cause by writing separate code which also causes this error. An analogy may help here. Suppose your car made an annoying rattling noise, but only rarely and in a hard to reproduce way. You won't fix this by taking another car, putting a load of sheet metal in the back and driving it around until you hear rattling. But this is, in effect, what you are attempting.Quote:
Originally Posted by wodin
To be honest with you, you should always anticipate any errors that may occur, including crashes.Quote:
Originally Posted by wodin
Do you write to log files? If you did, you would have a rough idea of where the crash may be happening.
Have you invested the time in producing and processing crash dumps? If you did, you would have a file that you can "run" under the debugger to see what could have caused the crash.
So why did you wait until it happened 4 times? Where I work, if it happened one time, we get to work figuring out what's wrong. If that means writing more information to log files, or set up a crash dumper to generate dump files, run our app through memory checkers/leak detectors, then that's what we do. The problem is then diagnosed, or if not, we have a good idea what causes the problem and will be ready if it occurs again.Quote:
this error comes very rarely, out of 4 years of operations only 4 times it has occured.
Putting things off until you get demands from the customer to fix the problem could have been avoided by diagnosing the problem much sooner.
Regards,
Paul McKenzie
many thanks for your honest and sincere reply. we have handled much of the error and crash vulnerabilities with log writing. First time when this particular issue came we analyzed our logs but found nothing. Second time we had told the client to enable doctor watson as the default debugger, so that we can analyse the drwatson log file to locate the fault point, but for this crash dr watson simply did not write anything. we have done drwatson debugging with other client sites and fixed the issues many time...so Third time we did more check up through out the code for any memory leaks but nothing significantly found. Now we have decided to run ProcessExplorer and get the dump file if this issue come again..(precisely to do this exercise in anticipation before the issue at client site we want to simulate and see whether ProcessExplorer dump file will help or not)
Then write your own crash dumper. It is done by setting the crash handler in your program and calling functions in DBGHELP.DLL to write the dump file. Our company never relies on Dr. Watson being enabled or even working on the customer's machine -- writing your own dump is the only way to guarantee you will get one.Quote:
Originally Posted by wodin
Please search here or the web for writing your own crash dumps -- there are many articles on how to do this.
Regards,
Paul McKenzie
ok,thanks a lot.