New to BB as I've just download madExcept and been working with it all day today.

I've tried everything, but I cannot get madExcept to recognize when an 'invalid pointer exception' or 'Access Violation Occurs C000005' occurs to send me a report. Same with 'Invalid Pointer Operation'EnvironmentRunning Delphi 7 in x86OS: Windows2008R2Type: x64Compatibility for Delphi: WindowsXP SP3madEffect version: v4.0.16

Delphi is my second development platform, I develop in C#.net, so I'm probably missing something very obvious. So to that end, please let me know how I setup madExcept and the Delphi Debugger Options so that all errors are captured by madExcept, and a bugReport sent.

I did have exception handling included, but I removed the action statement but left the except statement.The Invalid Pointer error brings me into the CPU window, which essentially to me is meaningless(with addresses and such) as I cannot correlate the ASSEMBLER code to what actually is executing. I would prefer that something would stop on the statement in the IDE that is causing the error to trigger so I can then debug.

Please let me know if there is anything I can provide that will help solve my issue. I'm at my wit's end. The error occurs in some files and not in others, so I can't tell if it's something in the files or it's the code itself doing something it should not.

The IDE debugger is very eager to stop at any exceptions, right when they occur. madExcept is a bit more relaxed. It waits until all try..except blocks have run through, and only becomes active when no try..except block "handles" (resolves) the exception. Which means when you run your program inside of the IDE, madExcept won't become active until you tell the IDE debugger to "continue". Outside of the IDE that's not necessary, of course.

Thank you for replying. Yes and no as far as answer. I'm in the middle of debugging the application so it's not running unattended. So, I need to know how to have madExcept work in the IDE while the code runs. Do I alter the debugger options for all errors as user-handled? Do I remove all the except action statements but leave Try Except in place meaning that nothing occurs if an exception occurs(since I've commented out the do action?)

Also when the error occurs, I do not get a chance to continue, the only button that is available is OK and a check box to 'View CPU Window'. The dialog box give me the address of the violation.

I don't think I can save the CPU window to a log. Here's the other issue. I'm the only DELPHI developer at my company. So I've no other resource to ask. And, as I mentioned, this is not what I usually develop in and inherited this app when the actual DELPHI programmer left. At that time I did not know Delphi at all. What that boils down to is I only program in Delphi for this project and it's usually month(s) or year(s) in between when a change is required.

Any help you can offer so I can pinpoint the issue would be great. Let me know if I can provide anything from the debug run that would help.

You don't need to change any Delphi settings. You simply tell the IDE debugger to continue to run the program, after it has stopped at an exception. It's as simple as that.<AINKLES>OK

Does everything work as expected when running the exe outside of the IDE? <AINKLES>I've not tried as I'm debugging it. Also the actual end product is a Delphi DLL called by a c#.net app. I've written a test program in Delphi that calls the necessary units that comprise the dll for testing

Do you have try..except blocks in your code? If so, what do they do?<AINKLES> Nothing now, I've removed the action that raises the error and writes the error to a log file I maintain. The calling program would actually display the error as that's a forms(or windows app), the others raise the error thru the chain of callers until the form is the last recipient and displays.

The app purpose is this. It reads in and writes out a file comprised of names and addresses. During processing specific information(i.e. firm) is analyzed and as such it's used as lookups to several "text" tables to see if any cleansing can be done. I've highlighed the code below where I think the app is tanking. I have several of these "binarySearchf" routines(to different files) throughout the app. My theory is either it cannot read from m_fptAbbrev file(defined as file not textfile) and suffixNumber returned is 0(if I see the value). When it works, it either finds the data it's looking for and does the replace OR it doesn't and exits routine.

the previous programmer used pointers, which while faster, requires a lot of overhead to convert to and from strings to maintain the pchar. I stay away from pointers usually because they are more trouble than they are worth in my eyes. He also did NOT have any error checking, so the error would call up the chain to the caller and stop. Any error checking has been added by me. The stripSuffix routine below mostly is legacy except for the error checking I added. This was the result of trying to pinpoint the issue.

A dll normally doesn't handle exceptions by itself. If you want your Delphi dll to handle its own exceptions, you need to put a try..except block around every "entry point" of your dll. And entry point is a exported function of your Delphi dll that might be called by your C# program. The try..except block needs to look like this:

Update: I've added error routines to anything I think might be an issue. While helpful, still not seeing what the issue is. Some Files run thru file, others, something about a record or perhaps the file causes Invalid pointer exception. I've uploaded the bug report I did manage to receive. my last resort is to bypass the record when the error occurs and then just continue processing the rest of the file. Is that doable?

The program reads in text files(defined as file...not my first choice) and use pchar variables through-out the processing. I have been at this for days and am no closer to solving the issue. I know Delphi a lot better, but that is no consolation.

Can I bypass the error if it occurs on a record, and instruct the program to continue reading from the next record? At some point, I'm going to have to run more test files for my CEO and at this point, I don't know what the trigger is.

TEST20170317 does not read in cleanly, only the first 1-2 records process and then it tanks.AV_TEST_FILE runs to completion without a problem.

I've looked at the TEST file in hex and do not see any issue. I'm desperate.

This is what is processed from the TEST file:

MC->COMPANY:AMER SOC OF TOM S TESTING MC->ROUTINE COMPLETEDCB->COMPANY: AMER SOC OF TOMS TESTINGCB->FIXPOSSESSIVES COMPLETEDCB->ROUTINE COMPLETED********************************MC->COMPANY:AMER SOCIETY OF TOM S TESTING <- this is where I think it tanked as it's the last log entry.

I have to run the error C00005 in the debbuger options as User Handled and Run Unhandled. If I indicate Run Handled....the program just stops unbeknownst to me with no indication that something has occurred.

avinkles wrote:Update: I've added error routines to anything I think might be an issue. While helpful, still not seeing what the issue is. Some Files run thru file, others, something about a record or perhaps the file causes Invalid pointer exception.

Do you get a madExcept report for those? Are you still testing this inside of the Delphi debugger? If so, did you tell the debugger to continue running the program after is stopped at the exception?

avinkles wrote:I've uploaded the bug report I did manage to receive.

Where?

avinkles wrote:my last resort is to ...

Right now you don't even have the basics working. I don't think it's the right time to think about last resorts. You need to make the basic exception handling work first. Try with some logic:

Add *intentional* crashes to your Delphi DLL. E.g. do "integer(nil^) := 0" to raise an access violation. Then check if madExcept catches and reports it. Only after you got that working, you can start analyzing the real crashes in your DLL.