Why no mbr file?
Why no mbr file?
Using madExcept version 5.0.0, 64bit application (Delphi 10.2.3)
Although my application crashes (yes deeply ashamed) and MS windows shows an info popup about the crash, I can't find a mbr file afterwards. I'm sure my setup of madExcept is ok (I've did a test to force an exception which generated a .mbr file).
Is there already a new version of madExcept available?
Regards,
Pascal
Although my application crashes (yes deeply ashamed) and MS windows shows an info popup about the crash, I can't find a mbr file afterwards. I'm sure my setup of madExcept is ok (I've did a test to force an exception which generated a .mbr file).
Is there already a new version of madExcept available?
Regards,
Pascal
Re: Why no mbr file?
You can use this build which is somewhat newer, but it's not much different, and it is very unlikely to fix this problem:
http://madshi.net/madCollectionUpdate.exe
There are some kind of exceptions that madExcept cannot properly report. For example, imagine the memory manager gets broken so that each call to the memory manager produces another access violation. madExcept does need to allocate memory. So in this situation madExcept can't work properly. This is just one example, of course, there are others.
Can you reliably reproduce the crash on your dev PC? In that case please activate "instantly crash on buffer overrun". This feature consumes a lot of RAM, though, so if you have bad luck, your program will run out of RAM when using that feature. But if it doesn't, this feature should raise an exception if you have any kind of buffer overrun in your code. That might help finding the real cause of the wild crash you get atm.
http://madshi.net/madCollectionUpdate.exe
There are some kind of exceptions that madExcept cannot properly report. For example, imagine the memory manager gets broken so that each call to the memory manager produces another access violation. madExcept does need to allocate memory. So in this situation madExcept can't work properly. This is just one example, of course, there are others.
Can you reliably reproduce the crash on your dev PC? In that case please activate "instantly crash on buffer overrun". This feature consumes a lot of RAM, though, so if you have bad luck, your program will run out of RAM when using that feature. But if it doesn't, this feature should raise an exception if you have any kind of buffer overrun in your code. That might help finding the real cause of the wild crash you get atm.
Re: Why no mbr file?
No I can't reproduce this. I've a couple of users with the same issue. Also did the the with the buffer overrun but got no exception.Can you reliably reproduce the crash on your dev PC? In that case please activate "instantly crash on buffer overrun". This feature consumes a lot of RAM, though, so if you have bad luck, your program will run out of RAM when using that feature. But if it doesn't, this feature should raise an exception if you have any kind of buffer overrun in your code. That might help finding the real cause of the wild crash you get atm.
Can you please explain what you mean with 'gets broken'.For example, imagine the memory manager gets broken
Re: Why no mbr file?
A random buffer overrun can destroy important data, so that e.g. a memory manager trying to do something results in a crash. For example, if a function pointer is overwritten with a random value, the thread trying to call that function pointer will always jump to a random location, which will automatically lead to a crash (or to even worse damage).
Did you try the buffer overrun check on your own PC, or on the PC of the end user who has this problem? The buffer overrun check will only work if madExcept can find the madExcept32.dll. On your dev PC madExcept will find that automatically. But the end user doesn't have the file. So if you want the buffer overrun check to be performed on the end user's PC, you need to distribute the madExcept32.dll with your EXE file (same folder). But before you do that I recommend that you test your program with the buffer overrun check enabled on your own PC, just to make sure it doesn't run into "out of memory" problems.
Did you try the buffer overrun check on your own PC, or on the PC of the end user who has this problem? The buffer overrun check will only work if madExcept can find the madExcept32.dll. On your dev PC madExcept will find that automatically. But the end user doesn't have the file. So if you want the buffer overrun check to be performed on the end user's PC, you need to distribute the madExcept32.dll with your EXE file (same folder). But before you do that I recommend that you test your program with the buffer overrun check enabled on your own PC, just to make sure it doesn't run into "out of memory" problems.
Re: Why no mbr file?
https://stackoverflow.com/questions/166 ... ad-program
The above link is the same exception as the one I received from my user (0x0eedfade).
Googled a lot for this 0x0eedfade and at the end I found https://www.thedelphigeek.com/2007/04/m ... tting.html
Would (don't laugh) enabling 'range check' help me finding issues like buffer overrun?
The above link is the same exception as the one I received from my user (0x0eedfade).
Googled a lot for this 0x0eedfade and at the end I found https://www.thedelphigeek.com/2007/04/m ... tting.html
Would (don't laugh) enabling 'range check' help me finding issues like buffer overrun?
Re: Why no mbr file?
A range check finds *some* buffer overruns, but not all.
Re: Why no mbr file?
Enabled range check and after many many tries... Range check exception in a third party unit. The allocate was not correct handling 64 wparam and lparam.
Resulting mbr file told me where I had to look
Resulting mbr file told me where I had to look
Re: Why no mbr file?
So did this solve the original problem?
Re: Why no mbr file?
Yes it did
Re: Why no mbr file?
strange-0x0eedfade-exception-in-delphi-multi-thread-program
I spoke too soon. It came back but now definitely fixed (we found a way to replicate it on our system). It was a bug in the Pascal Script code. Affected only 64 bit version. Updated to latest svn and it is fixed. Maybe somebody can use this info later, you never know. Always generated this 0x0eedfade exception.
Is there a reason why madExcept doesn't seem to catch exceptions from/within the Pascal Script source (https://github.com/remobjects/pascalscript)
I spoke too soon. It came back but now definitely fixed (we found a way to replicate it on our system). It was a bug in the Pascal Script code. Affected only 64 bit version. Updated to latest svn and it is fixed. Maybe somebody can use this info later, you never know. Always generated this 0x0eedfade exception.
Is there a reason why madExcept doesn't seem to catch exceptions from/within the Pascal Script source (https://github.com/remobjects/pascalscript)
Re: Why no mbr file?
See my first reply.