6.0.21 handles exceptions explicitly left unhandled

[OlliS]

Hello,

We have an application that is Certified for Windows Vista. Due to this the application is required to pass external exceptions to the system for Windows Error Reporting to handle, which we do with a custom Application.OnException -handler and an exception filter added for External exceptions.

EurekaLog 6.0.21 has the following change listed
"4)...Added handling for unhandled exceptions in certain specific cases;"
which apparently disables this mechanism and causes the process just to vanish when for example an access violation occurs, without showing the WER dialog or writing an ELF.

We have identified EurekaLog as the cause of the behaviour, as the same application built with 6.0.18 works as expected.

How this new behaviour can be disabled or controlled?

[Alex]

Hi,

Sorry, but EurekaLog v6 does not support Certified for Windows Vista applications (this is planned for v7), so this behaviour can not be altered or disabled.

The following code was added in the last version (ExceptionLog.pas):

function CustomHandler(AExceptionInfo: PEXCEPTION_POINTERS): Cardinal; stdcall;
type
TGetExceptObj = function(P: Pointer): Exception;
var
E: Exception;
begin
CannotUseThread := True;
E := nil;
if ExceptObject is Exception then
E := Exception(ExceptObject);
if not Assigned(E) then
begin
if (AExceptionInfo^.ExceptionRecord^.ExceptionCode = cDelphiException) and
(IsDelphiException(Pointer(AExceptionInfo^.Excepti onRecord^.ExceptionInformation[1]))) then
E := Exception(Pointer(AExceptionInfo^.ExceptionRecord^ .ExceptionInformation[1]))
else
E := TGetExceptObj(ExceptObjProc)(AExceptionInfo^.Excep tionRecord);
end;
if E = nil then
begin
E := EExternalException.CreateFmt(SExternalException, [AExceptionInfo^.ExceptionRecord^.ExceptionCode]);
EExternalException(E).ExceptionRecord := Pointer(AExceptionInfo^.ExceptionRecord);
end;

if LastExceptMessage <> PurgeString(GetExceptionMessage(E)) then
StandardEurekaNotify(E, AExceptionInfo^.ExceptionRecord^.ExceptionAddress) ;
TerminateProcess(GetCurrentProcess, AExceptionInfo^.ExceptionRecord^.ExceptionCode);
Result := 0;
end;

initialization
SetUnhandledExceptionFilter(@CustomHandler); // setup custom handler

You only need to remove that "SetUnhandledExceptionFilter" line in initialization section.

If you only have a professional version, then you may try to override it manually (like saving old handler before ExceptionLog and restoring it after), but I didn't experiment with it.

[OlliS]

We have had a shipping product using EurekaLog with a "Certified for Windows Vista" logo for over two years, so while it's not possible to have any valid data from WER (which incidentally is more of a Delphi than EurekaLog issue), your statement that such applications are not supported by EurekaLog is factually incorrect. I also do not believe that I've seen any language to that effect in EurekaLog documentation either.

Only relevant certification requirement is that the process does not handle external exceptions, which is fulfilled by letting such exceptions out of the process - i.e. leaving them unhandled at the main exception handler. There are also other perfectly legitimate uses for explicitly leaving exceptions unhandled.

We have had successful solution for this until 6.0.21. Behavior of the product that has remained the same for minimum of two years has been drastically changed in a point release. Furthermore there is no documentation to be found stating either that the behavior is incorrect, subject to change, unsupported or that relying to it is not recommended.

Therefore from where we stand this change is definitely a bug.

We've been mostly satisfied with the product until this point, but it now appears from this that we'll have to initiate serious evaluation whether it's at all possible to continue to use EurekaLog in our products.

While we do have the Enterprise edition, having to make further customizations to the EurekaLog code to restore previous functionality that was changed abruptly is not valid solution.

[Alex]

Hi,

Ummmm... while personally I agree with reasoning "do not handle unhandled exceptions" (that's why we consider adding full suport for WER in v7) - this is just NOT what most of our customers want.

They want EurekaLog to be able to catch any exception in their application and this is what this change do.

You're asking us to revert this change, but I afraid that this would go against desires of majority of our clients. Look, this change have not appeared for no reason here, as we have many (angry) reports about EurekaLog not being able to catch exceptions in certain cases.

If you don't want to use workaround, how about if we add some hidden switch (global variable), which you can use to prevent EurekaLog from hooking this handler? Ummm... but since you still need to add a separate unit for this, then I suspect that this would be not much of help :(

If you have other suggestions about acceptable solution for you - feel free to tell us (well, except of "get rid of this new change completely!" - as this is unacceptable for us ;) ).

[OlliS]

that's why we consider adding full suport for WER in v7

Is there any timeline or roadmap for v7?

if we add some hidden switch (global variable), which you can use to prevent EurekaLog from hooking this handler? Ummm... but since you still need to add a separate unit for this, then I suspect that this would be not much of help :(

If you have other suggestions about acceptable solution for you - feel free to tell us (well, except of "get rid of this new change completely!" - as this is unacceptable for us ;) ).

Any way to disable handling of unhandled exceptions from project code using EurekaLog, without having to modify the EurekaLog sources, would be fine.

[Alex]

Is there any timeline or roadmap for v7?
Sorry, there is no estimates, but we're actively working on development.

Any way to disable handling of unhandled exceptions from project code using EurekaLog, without having to modify the EurekaLog sources, would be fine.
Then can you explain, what is wrong with suggested workaround, please? It does not require changing EurekaLog code. I mean this one:
override it manually (like saving old handler before ExceptionLog and restoring it after)

Do you need an example?

Create unit:

unit SaveHandler;

interface

var
SavedUnhandledHandler: TFNTopLevelExceptionFilter;

implementation

procedure Dummy;
begin
end;

initialization
SavedUnhandledHandler := SetUnhandledExceptionFilter(@Dummy); // I'm not sure if SetUnhandledExceptionFilter can accept nil
SetUnhandledExceptionFilter(SavedUnhandledHandler) ;

end.

And place it into uses clause right before ExceptionLog. This would save handler from WER into SavedUnhandledHandler variable.
You can restore it in any convenient moment (by calling "SetUnhandledExceptionFilter(SavedUnhandledHandler) ;").