Lockups with TakeCommand v12

[bquinlan]

I finally upgraded to v12 a few days ago. Since then I have had my TakeCommand window lock up at least three or four times per day. The window just stops responding and soon after that it grays out and shows "(Not Responding)" in the header. I have to kill and restart it each time.

There is no obvious pattern to what I'm doing when the lockups occur. The problem started when I upgraded from v11 to v12. I am running the x64 of Take Command (v12.01.44) under Windows 7 Home Premium (v6.1.7600).

Are other people seeing this? Any idea what might be causing it?

--Bob Q

 

[rconn]

Are other people seeing this? Any idea what might be causing it?

A handful of people reported this when v12 was released, though nobody ever found a reproducible failcase (and I was never able to reproduce it here). I haven't heard of any cases recently until yours.

Most people seemed to be able to resolve the problem by deleting & recreating their TCMD.INI, so you might try that first. (Well, *first* make a backup copy, so if it no longer locks up with the new TCMD.INI, you can send me your old one.)

 

[bquinlan]

Based on your suggestion I just re-created my TCMD.INI. With any luck that will eliminate the lockups.

I guess it isn't too surprising if that file has gotten kind of strange. Mine probably had stuff going back to 4DOS in it. :)

Thanks for the help!

--Bob Q

 

[Kachupp]

If it had any 4dos directives in IT, it would of been FINE at least it would of
told
you the offending line

> -----Original Message-----
> Subject: RE: [Support-t-2580] Re: Lockups with TakeCommand v12
>
>
> Based on your suggestion I just re-created my TCMD.INI. With any
> luck that will eliminate the lockups.
>
> I guess it isn't too surprising if that file has gotten kind of
> strange. Mine probably had stuff going back to 4DOS in it. :)
>
> Thanks for the help!
>
> --Bob Q
>
>
>
>

 

[Jim Cook]

The only odd trouble I had was a vanishing TCMD, but I had inadvertently
loaded an old DOS TSR program and then ... well, welcome rabbit hole. I
didn't feel that I especially needed to point fingers at TCC/TCMD for that
one.

On Sat, Feb 5, 2011 at 00:36, Kachupp <> wrote:

> If it had any 4dos directives in IT, it would of been FINE at least it
> would of
> told
> you the offending line
>
>
>
>
> ---Quote---
> > -----Original Message-----
> > Subject: RE: [Support-t-2580] Re: Lockups with TakeCommand v12
> >
> >
> > Based on your suggestion I just re-created my TCMD.INI. With any
> > luck that will eliminate the lockups.
> >
> > I guess it isn't too surprising if that file has gotten kind of
> > strange. Mine probably had stuff going back to 4DOS in it. :)
> >
> > Thanks for the help!
> >
> > --Bob Q
> >
> >
> >
> >
> ---End Quote---
>
>
>
>

--
Jim Cook
2010 Mondays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Tuesday.

 

[bquinlan]

I deleted my TCMD.INI file and rebuilt it using the dialogs, just to make sure it was entirely clean.

Unfortunately I am still seeing lockups fairly often. I just had three of them happen in less than ten minutes. There are a couple of things I have noticed that seem to represent a pattern.

First, TakeCommand is most likely to lock up at the instant I return to it as the active window. This happens before any keypress or mouse action occurs. I just click on the window border or <Alt-Tab> into it and the TC window goes gray and shows "Not Responding" in the header.

Second, vim.exe for Windows (from the gvim v7.3 package) is most often running in the window when it locks up. That may just be because I use vim an awfully lot, but it could also be some kind of interaction. I have seen TC lock up when vim was not present.

Is there anything I can do to capture more information for you when lockups occur? Any ideas about other things I can try?

--Bob Q

 

[bquinlan]

And to add one more thing...

I had just restarted the window after a lockup and shifted away from it to do something other stuff without having done anything. The instant I clicked back on it the window locked up. It had not received a single keypress or mouse click since it started. All that happened was it lost focus and regained it.

--Bob Q

 

[bquinlan]

TakeCommand is now locking up almost every time I switch back to it from another window. It also stops responding during other routine tasks, even when it does not lose focus. I have no idea what I've done to make it worse, although it may just be that I'm trying to use it more than I had been.

I have tried uninstalling TakeCommand and removing all of its configuration files and directories. then reinstalling from scratch. I have tried rebooting my machine several times. Nothing seems to help.

I had to re-install v11 this morning. I have never had a problem with it and it is still working perfectly.

Can anyone suggest other things for me to try to get v12 working? Is there any diagnostic data I can pull? Now that it's dying all the time it would be relatively simple to do.

--Bob Q

 

[rconn]

> Can anyone suggest other things for me to try to get v12 working? Is

there

> any diagnostic data I can pull? Now that it's dying all the time it would

be

> relatively simple to do.

Does it also happen if you only have a single tab open?

Do you have any other processes that are injecting dll's into TCMD?

 

[rconn]

> Can anyone suggest other things for me to try to get v12 working?

There's no way to get any diagnostic info out of a process that's not
responding -- unless you have Visual Studio and can debug the process &
break out of whatever it's doing.

But there's only one source module where v12 *could* hang. It's easy to
revert that one module back to v11 and see if the problem goes away. If it
does, then I can try adding the 15-20 changes between v11 and v12 back in (a
few at a time) and see where it fails.

Let me know if you're willing to test this, and I'll put a test build on the
ftp site for you to try.

Rex Conn
JP Software

 

[bquinlan]

Does it also happen if you only have a single tab open?

Do you have any other processes that are injecting dll's into TCMD?

Nearly all of the lockups have happened with only a single tab open.

I'm not aware of any other processes that would directly affect TCMD. There are plenty of processes running in the background, but none that should interact with either the TakeCommand window manager or the TCC command-line interface.

I did try running TakeCommand v12 with TCC v11 as my command-line and that did not seem to have any problems.

--Bob Q

 

[bquinlan]

There's no way to get any diagnostic info out of a process that's not
responding -- unless you have Visual Studio and can debug the process &
break out of whatever it's doing.

But there's only one source module where v12 *could* hang. It's easy to
revert that one module back to v11 and see if the problem goes away. If it
does, then I can try adding the 15-20 changes between v11 and v12 back in (a
few at a time) and see where it fails.

Let me know if you're willing to test this, and I'll put a test build on the
ftp site for you to try.

Rex Conn
JP Software

I do not have Visual Studio, but I would be more than happy to try out test builds. Just let me know where to pick them up and I'll get back to you with results.

I know this is at least as frustrating for you as it is for me and I really appreciate this.

I will keep checking this space, but you can also reach me directly at [email protected] if that would be easier.

Thanks!

--Bob Q

 

[evanb]

I have also experienced this numerous times, although the during last couple of days it has happened only once or twice. Today (8 Mar) I discovered a reliable way to trigger it: I open the List View on a folder containing a 7-Zip archive that itself is an archive of a folder. (7-Zip 9.20.0.0; the 64-bit version, with context menu integration enabled.) In the List View I right-click on the archive, and from the 7-Zip commands select Extract here. 7-Zip extracts to a temp folder, then copies or moves the contents to the current folder. At the point where the copy/move occurs, Take Command stops responding. Another likely key to the puzzle is that I have selected Update Folders view on Directory Creation / Deletion in TC's Advanced settings tab.

I have also noticed that, when I drag a folder into the List View, that folder's contents are copied directly to the displayed folder, while the source folder itself is not copied at all. Perhaps the problems are related?

 

[rconn]

I have also experienced this numerous times, although the during last couple of days it has happened only once or twice. Today (8 Mar) I discovered a reliable way to trigger it: I open the List View on a folder containing a 7-Zip archive that itself is an archive of a folder. (7-Zip 9.20.0.0; the 64-bit version, with context menu integration enabled.) In the List View I right-click on the archive, and from the 7-Zip commands select Extract here. 7-Zip extracts to a temp folder, then copies or moves the contents to the current folder. At the point where the copy/move occurs, Take Command stops responding. Another likely key to the puzzle is that I have selected Update Folders view on Directory Creation / Deletion in TC's Advanced settings tab.

If you disable the "Update Folders" option, is the problem still reproducible?

I have also noticed that, when I drag a folder into the List View, that folder's contents are copied directly to the displayed folder, while the source folder itself is not copied at all. Perhaps the problems are related?

I don't understand what you're saying here. Can you give an explicit example?

 

[JohnQSmith]

I think this is what evanb is saying...

1. List View is showing the contents of Folder1.
2. Elsewhere exists Folder2 containing File1, File2, and File3.
3. Dragging Folder2 from either the Folder pane or from Windows Explorer into the List View is copying File1, File2, and File3 from Folder2 to Folder1 instead of copying Folder2 and its contents to Folder1.

That is what I think evanb is saying.

However, I tried this and got different results. When I try to do this nothing is copied at all, even though the mouse cursor changes to the pointer with the little plus sign in the lower right corner (meaning copy) while dragging Folder2 into the List View.

 

[bquinlan]

If you disable the "Update Folders" option, is the problem still reproducible?

That's an interesting question... After nearly constant lockups during the first few days of TC12 it suddenly became reliable. I still have the "Update Folders" option checked, but I have been keeping the folders element hidden. That might explain why it stopped locking up for me.

Thank you for continuing to investigate this!

--Bob Q

 

[evanb]

JohnQSmith's explanation of my scenario is spot-on except that I did not try dragging from TC's folder view, only Windows Explorer. Today, possibly because it is Wednesday rather than Tuesday, I get the same result as he does when dragging a folder into the list view: nothing is copied.

As for the "7-Zip scenario", I can only lock up Take Command if the "Update Folders" option is selected. If I deselect it there is no problem.

Further experimentation shows that the lock-up has nothing to do with 7-Zip; it occurs when some process (including TC itself) copies a folder into the folder displayed in the Take Command List view window.

You can see it for yourself:
- Tick the "Update Folders view" option on the Take Command Advanced options page.
- open TC's List view on a folder; call it FolderA.
- open a Windows Explorer window on FolderA.
- with Windows Explorer, copy (don't move) a folder into FolderA.
TC stops responding.

 

[rconn]

You can see it for yourself:
- Tick the "Update Folders view" option on the Take Command Advanced options page.
- open TC's List view on a folder; call it FolderA.
- open a Windows Explorer window on FolderA.
- with Windows Explorer, copy (don't move) a folder into FolderA.
TC stops responding.

I finally managed to reproduce this (after trying it on four machines that *didn't* hang). Further investigation shows that it's hanging deep inside Windows -- I can't fix that, but hopefully I can find a way around it.