Take Command sometimes hangs on startup with WindowBlinds installed

If the app hangs on startup and it is excluded then chances are the problem is in Take Command not WindowBlinds.

I might be asking a stupid question, but might you also be having too much starting at once. Seems to me that perhaps Take Command could delay the start of other programs until after WB is fully loaded.

If you opt to start that way, and if you still have a problem, I'd say Neil might well be correct.

I also read and participated with the blue screens thread by messiah1, and agree that the less you meddle with, the better off your system tends to be.

Try what I suggested, if only to see where the problem might be occurring....

But it works absolutely fine without WindowBlinds. And even those times when it doesn't hang, it works several times faster without WindowBlinds! That's for sure. I checked it several times.

I analized the stack trace of the hanged threads. They indicate that the hang occurs during CreateWindowEx call.

I adressed this issue in the forum of JP Software. They think (and I agree) that the problem is not of Take Command.

If you are interested in the investigation of the issue, you can discuss it in the discussion thread I created in JP Software forum: http://jpsoft.com/forums/showthread.php?t=1706 . There you can find the Process Monitor logs.

What do you mean?

It knows nothing about WB, which is right, how possibly it can delay anything until WB load?

What way?

I do not meddle with anything. I just need Take Command for my work. And with WindowBlinds Take Command doesn't work.

Hmm... I really do not understand what are you suggesting.

My error. I thought it determined boot sequence. Perhaps if you alter your boot sequence to have WB start and fully finish booting before Take Command boots (or just not have it in your startup programs but rather open only when you need it) the problem will be resolved.

I might be misunderstanding. Could it be that the Take Command GUI conflicts with WB7's? If so, excluding it from WB7 should have solved the problem. There must be something else in that program conflicting with WB7. If that happens no matter what you do, and the Total Command is critical to your work, you might have to sacrifice WB7 on that machine, or try earlier versions of WB (WB6.4) if that worked without conflict. Sorry for your trouble, noxmetus.

As far as I understood, the word "startup" not necessarily means startup of Windows or PC. I am sorry if I was wrong. I meant the launch of Take Command. It has nothing to do with the boot process.

But WB is what responsible for GUI. It can only conflict with itself.

In my first post I mentioned that it doesn't help. Only complete removal of WindowBlinds solved the problem.

Of course, no doubt .

Right . Only Take Command, not Total.

 

Thanks .

Unfortunately the logs attached to that post require forum access and they appear to have manual procedures for accepting new accounts so right now I cannot access any of the files.

What OS are you using?

Neil, if you really want to investigate the issue, I can send you whatever logs you want, help with debugging, tracing and nailing down the problem.

I am using Windows 7 x64. Manifestation of the issue: when WindowBlinds is installed, every run of tcc.exe (this is actual command line processor from tha Take Command, a console application) takes a long, long while. Every so often the next launch of tcc.exe not just takes a while, but hangs completely. Process Monitor shows that it hangs after starting several therads, each one has CreateWindowEx in its call stack. Take Command's author stated that these threads are not from tcc.exe. I don't know what creteria he used, but anyway... could it happen that WindowBlinds causes some extra threads to start on a program launch? Do you need the Process Monitor log? Do you want me to do some other experiments to identify the problem?

Why it is always like this with not free software? Whenever you offer your help to solve a problem with their software, tech guys just silently dissappear. It seems like they are never interested in solving problems. As strange as it may sound it is very often much easier to get real help with free and open source sofware. I found several bugs in WindowBlinds, beginning from visual artifacts, ending up with compatibility problems. All that the support could offer is an advice to check my installation and reinstall. After that they just dissapeared and ignored my consequent letters that reinstallation doesn't help. The forum at the first glance promised more help. But this hope was equally futile.

 

Btw, I was able to reproduce the bug on Windows 7 x86 as well.

noxmetus - Do you have a trouble ticket number from support? If so, please post that number here.

We know exactly what the issue is, but unfortunately it requires an update to a file thats got some very special signing requirements which is why the latest WB release did not resolve the problem.

There is something about TakeCommand thats causing a deadlock in the process load when WB loads up some other dlls (note that this isn't being called from DllMain which obviously could cause such issues).  No other app has ever shown this, so it appears to be a highly unusual conflict.

I haven't created a ticket for this particular issue, since the support showed itself sometimes useless. I posted the issue directly here. There is another issue I've submitted a ticket for and I had no response from the support other than check the installation. Are you interested in its number?

Hello Neil. Thank you for the response.

So the deadlock occurs on LoadLibrary call?

Was the issue solved? I do not use WindowBlinds since February, despite I paid for it.

I believe the most recent update to WindowBlinds contains a change which should have resolved this problem.