john-spackman
Member
I've discovered an Access Violation problem with the OracleMonitor interface code; it occurs where DOA is used in seperate processes which are running under different user accounts.
The TMonitorClient instantiates TEvent objects which call CreateEvent with a name of DOAMonitorEvent, and subsequent processes get a handle that refers to the same event object. Fine so far, but if one of those processes is running as a different user account (in my case, one was an NT service that was running logged in as the default LOCALSYSTEM account and another was a normal interactive app, but I guess this might happen with XP's fast-user-switching facility also) then CreateEvent fails with an Access Denied error.
The Access Violation is caused because the TMonitorClient is instantiated during the Delphi RTL's initialization and when CreateEvent returns 0 the TEvent object calls Abort. Unfortunately the RTL initialization doesn't handle exceptions and the result is an access violation - no other error message, just an AV.
The workaround was to get my service to start logged in as the same user who is running the interactive app, but obviously that's not suitable long term for a variety of reasons (multiple users, service needs higher security rights than interactive user, etc).
I'd like to suggest that Abort is removed from the code and replaced with an actual raising of an exception - I've tried it and at least that way you get an indication of a problem, whereas Abort just screws your process and you have NO idea what/where/why went wrong.
Many thanks for an otherwise excellent product!!
Ta,
John.
The TMonitorClient instantiates TEvent objects which call CreateEvent with a name of DOAMonitorEvent, and subsequent processes get a handle that refers to the same event object. Fine so far, but if one of those processes is running as a different user account (in my case, one was an NT service that was running logged in as the default LOCALSYSTEM account and another was a normal interactive app, but I guess this might happen with XP's fast-user-switching facility also) then CreateEvent fails with an Access Denied error.
The Access Violation is caused because the TMonitorClient is instantiated during the Delphi RTL's initialization and when CreateEvent returns 0 the TEvent object calls Abort. Unfortunately the RTL initialization doesn't handle exceptions and the result is an access violation - no other error message, just an AV.
The workaround was to get my service to start logged in as the same user who is running the interactive app, but obviously that's not suitable long term for a variety of reasons (multiple users, service needs higher security rights than interactive user, etc).
I'd like to suggest that Abort is removed from the code and replaced with an actual raising of an exception - I've tried it and at least that way you get an indication of a problem, whereas Abort just screws your process and you have NO idea what/where/why went wrong.
Many thanks for an otherwise excellent product!!
Ta,
John.
