fatal error: background window not found

[wanderer]

Hi.

I connect to a virtual server which seems to be on a physical server which is overloaded. Several times, when trying to perform a background operation (i.e. copy a file), the message "fatal error: background window not found" appears. After a few seconds the window is shown but the process has already been aborted (since this message appeared). I guess it's a timeout inserted by Christian in order to validate that some things work properly. Is there a way to increase this timeout from the INI perhaps?

[ghisler(Author)]

No, this error message doesn't come from Total Commander itself. Maybe it's a Delphi or Lazarus exception? I have never seen it. The problem is, how could I reproduce this? Is this a public cloud service you use?

[wanderer]

No, it's a private server inside the local lan of a client. It seemed to come from total commander because when it appears, after a few seconds the window is shown and when i press OK i close the background tasks window and TC continues to work normally. No exception or anything, that's why i assumed it was something "expected".

If it's of any help, the server is a Win2K8x64 which was once physical and was P2V'd to a Microsoft Hyper-V server. It seems that sometimes the host server responds very slowly and that's when the problem occurs. It's not reproducible, it's rather random. I could send you the INI or perhaps try some special "debug" TC version if you wish (as long as it will not do anything crazy since this is a production server )...

I'm using TCx64.

P.S.: Remind me please, which was the last pre-Lazarus TC version? I could try that for a while and see what happens. Perhaps i could try them in parallel to see if when this problem occurs with one version, it also occurs with the other...

[ghisler(Author)]

The 32-bit version is still compiled with Delphi, not Lazarus. Only the 64-bit version is compiled with Lazarus.

But I was wrong, "fatal error: background window not found" does come from TC, it's just not translated!

It is shown when you try to open the background transfer manager (F5 - F2) and it fails to open for 5 seconds. TC starts the background transfer manager (btm) thread, which then creates btm the window. If the system is very very busy, it can take more than 5 seconds to open that thread, but it should be very rare - 5 seconds without response is very bad.

Solution: Open the btm manually via menu commands - background transfer manager. TC will then use that, and will not close it when the operation is done.

[wanderer]

5 seconds without response is very bad.

It is indeed bad and there's not much i can do about it. That's why i asked if it's possible to define this interval via the INI.

Solution: Open the btm manually via menu commands - background transfer manager. TC will then use that, and will not close it when the operation is done.

AlwaysCopyInBackground=2
AlwaysPackInBackground=3
AlwaysUnpackInBackground=3

As you can imagine, it will take some time to get used to this workaround, but thanks for the tip.

I wonder though, why have such a technique? In my case at least, the window eventually opens. It may take up to 10 seconds but it does open. Why abort the process and not give it a chance to continue, even though it's that slow?

I know it's a rather unique situation so i wouldn't dare ask for any major changes in TC but would it be possible to increase the interval or if you wish, perhaps make it configurable (i.e. multiple of 5 - 0 or 1=5 seconds, 2=10, 3=15, up to 6 perhaps, i guess more would be very very extreme)?

[ghisler(Author)]

TC creates the window from the background thread, which has its own message queue, so it remains responsive even when TC itself is hanging. Normally starting a thread and opening a window should only take a small fraction of a second. I wonder what is slowing it down that much, must be hard to work under these conditions...

[wanderer]

Hmmm, now this is strange. It's not that hard to work because the only problem is what i described with btm which appears randomly. Other than that, the server's response time is somewhat slow sometimes, but workable. I'm guessing the server's cpu is maxed-out and perhaps there's some peculiarity of Hyper-V which causes the starting of a new thread to be extremely slow when the cpu is overloaded.

[ghisler(Author)]

Is Total Commander itself running from the server? Maybe Windows needs to fetch the dialog box from the EXE located on the network?

[wanderer]

Nope. Running from the server. Everything exists locally.

I worked with it again today and from time to time, the server responded very slow in general. For instance, when i rightclicked a file in TC, it took up to 7-8 seconds to show the context menu. Other apps were slow too (i.e. 7zip), it just that TC seemed a bit slower. Maybe it's my imagination...

[wanderer]

The workaround works fine. BTM opens instantly and when copy starts, it starts almost immediately. Perhaps the existing TC code for starting a new thread and opening btm should be altered a little...

[ghisler(Author)]

OK, I will compare the two methods, and try to find out what's different. I'm not aware of anything which could cause such a long delay...

[wanderer]

OK, I will compare the two methods, and try to find out what's different. I'm not aware of anything which could cause such a long delay...

A quick and dirty(or clean? ) way to find out the exact command which causes the delay could be to create a new tc.exe with msgboxes (msgbox "1", msgbox "2" and so on) between commands executed when copying a file (after F5 is pressed), and send it to me. I can run it and tell you after which point the problem appears so you can further research it. Either that or a simple log file.