Here's a strange one.  A handful of customers have recently started having an unusual problem.  On the client side, the application opens a TEDBSession component, then opens the TEDBDatabase component.

When the database is opened, the TEDBEngine component in the server application closes. No errors. Nothing.

The client application just sits there waiting and eventually times out.

Other customers aren't having this problem, and when I test it I don't have any problems either.

The other strange thing is, this is not new code.  It hasn't been changed for a very long time. I'm not sure what to make of it but I'm going to remote connect to these customers to try to work out what's going on.

RAD Studio XE7 and EDB 2.26 Build 4.

= Steve

I haven't been able to remote connect to the customers yet but I did some more of my own testing.  I wrote an automated test program to stress test the workstation application connecting to the server application.

A test cycle consists of running the application, the application connects to the server, logs in, and is then closed.

I had 3 workstations running the test program for 100 test cycles each, continuously and simultaneously.

Not one error and the server engine never stopped.

So I don't know what's going on with this handful of customers but it's going to be interesting trying to find out.

= Steve

I don't use the server myself, but can you compile it yourself? If so, something like madExcept might help pin it down, if something is killing it.


--

Matthew Jones

Steve


Are these the same group of customers you were having the other error with?

If so I would ask for a full hardware and software inventory, I'd also ask them to run a decent anti-virus scan and back that up with Malware Anti-malwarebytes and something like Adaware cleaner.

If its not the same group its worth a try anyway.

Just to clarify - the application doesn't get as far as opening a table or running sql? How often does it happen?

I am of course discounting programmer error <vbg> however, for the sake of completeness I would look at

If its a multithreaded application are all threads fully isolated?

Does it do any direct memory writing that could stomp on the engine's memory?

Is there anything there trying to start another instance of the engine?

Is there somewhere that the engines settings are altered and close to allow the alteration?

Does an extra strong extra black coffee make it work? If not does a shot of rum or whiskey help?

Roy Lambert

Hi Matthew,

<<I don't use the server myself, but can you compile it yourself? If so, something like madExcept might help pin it down, if something is killing it.>>

It's a custom server built from scratch because it has a lot more features like server auto-discovery and all sorts of notification options like emailing or texting admins when automatic backup have been performed or updates automatically installed.

Thanks I'll try MadExcept and see if it finds anything.

= Steve

Hi Roy,

<< Are these the same group of customers you were having the other error with? >>

No a different group of customer.

<< If so I would ask for a full hardware and software inventory, I'd also ask them to run a decent anti-virus scan and back that up with Malware Anti-malwarebytes and something like Adaware cleaner. >>

All of my application do extensive logging and I have a program they can run that collects the logs, hardware configuration, installed security software and emails it to me.  I made add all software.

<< Just to clarify - the application doesn't get as far as opening a table or running sql? How often does it happen?  >>

No, it only gets as far as attempting to open the database and then the engine stops.  If they restart the server service it often starts working again.  For this group of customers it happens every day.  The problem is their servers are maintained by external IT companies that don't like giving access to the servers, so it complicates troubleshooting efforts.

<< I am of course discounting programmer error <vbg> however, for the sake of completeness I would look at >>

Yep, always a possibility.

<< If its a multithreaded application are all threads fully isolated? >>

Yes it is but it doesn't get to the stage where any threads are run.

<< Does it do any direct memory writing that could stomp on the engine's memory? >>

No.

<< Is there anything there trying to start another instance of the engine? >>

No, everthing goes through the one instance.

<< Is there somewhere that the engines settings are altered and close to allow the alteration? >>

No.

<< Does an extra strong extra black coffee make it work? If not does a shot of rum or whiskey help?  >>

I think those would help tremendously, especially the rum or whiskey.  If I can get them to drink some then they won't really care if it's working or not.

= Steve

On 9/20/2017 6:51 PM, Steve Gill wrote:
> Here's a strange one.  A handful of customers have recently started having an unusual problem.  On the client side, the application opens a TEDBSession component, then opens the TEDBDatabase component.
>
> When the database is opened, the TEDBEngine component in the server application closes. No errors. Nothing.
>
> The other strange thing is, this is not new code.  It hasn't been changed for a very long time. I'm not sure what to make of it but I'm going to remote connect to these customers to try to work out what's going on.

My first suspicion would be recent windows updates and/or other system
changes that IT might be doing (total wild guess but did they react to
Equifax news by doing some extra sever lockdown for example).

I would ask for server change log and hope they have such a thing.

Raul

Steve


Apart from totally approving of your use of the rum (I do suggest one of the cheaper ones though) the only other thing that has occurred to me is duff ram.

Get them to run Windows built in memory tester. Its not brilliant but it will spot major problems.

Roy Lambert

Steve Gill wrote:

> It's a custom server built from scratch because

Okay, madExcept will help a lot then. The best thing is you can use it to debug exceptions while still handling them. And in your case, it could be that some lock is being taken, and then the exception occurs, and that kills the thread and stops others accessing the lock.

Most of my Thread Executes have a try/except in that ends like this:

   except
      on errInfo : Exception do
      begin
         HandleException(etNormal, errInfo);
         LogReport(leError, 'ThreadWhatever ERROR: ' + errInfo.Message);
      end;
   end;

The HandleException is a madExcept function, and madExcept is told to store and then continue automatically. This gets me the stack trace etc.

So if a thread fails, I get to know about it. If I handle an exception, I can still get the details later. Good luck!

--

Matthew Jones

I've added MadExcept so we'll see if it reveals anything.

= Steve