Marlon,
Thanks for the info. There is only one correction in your setup that I can determine from you explanation, and it may not be the cause of the hang.
1) To use an ActiveX Reference that is passed as a parameter to a remote sequence, you must configure the local client machine to give access permission to the user that is logged into the remote server machine. This is in addition to the DCOM configuration that you have change on the remote machine.
In other words, when you try and use the thread object from the local PC on the remote PC, the remote PC tries to access the owning application of the thread object, which in this case is on the local machine. If permission is not granted to do this, problems can occur.
You can grant access either on an application level or system level on the local machine. For Windows NT, you must complete the following steps to configure the security permissions for the local client on a system level.
1. Login using a userid that has administrator privileges.
2. Run dcomcnfg from the command line, which displays the Distributed COM Configuration Properties application window.
3. On the Default Properties tab, make sure that the Enable Distributed COM on this computer option is checked.
4. On the Default Security tab of the Distributed COM Configuration Properties application window, edit the default access permissions. You must give access permission to the appropriate users so that they can access the local client machine.
If you want to grant access permission at the application level, the application to configure is listed as Sequence File in the dcomcnfg dialog box.
So, I would try configuring DCOM, however, if this was the cause of the hang, I would expect an error to occur while using the Thread object rather than at shut down.
2) I believe that LWTCPJSOCKWNDYCLASS is a window that the CVI engine creates to handle TCP communication and that it creates this whether or not there is TCP communication. It's hanging might not be it's fault. It could be caused by something else that is corrupting its memory. It may take a method of elimination to determine the cause.
I have found one reference to a problem involving LWTCPJSOCKWNDYCLASS and a 6608 board, although I don't think the underlying cause was ever determined. Specifically, when the user removed the 6608 from MAX, the problem went away. One test that I would recommend trying in your application is to remove the 6601 from MAX to see if the problem goes away. Although I do not currently have a 6601 I can work to get one so that I can try and reproduce the problem. I need to track one down first.
3) I would try running simple or empty sequence remotely and shutting down. I would do this **BEFORE** removing the 6601 from MAX to see if the problem is related to something in your sequences or to the 6601 being configured in MAX.
If the problem does not occur, then you could then add to the empty sequence simple steps that only use the 6601.
If the problem still does not occur, then you could add steps involving other hardware in your system, trying to shutdown after adding steps for each different hardware device.
I think you get the picture; remove/add one component (e.g. max config, hardware specific steps) at a time until the problem disappears/appears.
4) As a last option, I could see converting to more recent versions of software that you are using (NIDAQ, VISA, LabVIEW, etc.), but at the moment this would be more out of desperation. I know that the 6608 problem I previously mentioned occurred with NI-DAQ 6.9.2, LV 6.0.2, Windows 2000, TestStand 2.0.1beta and Switch Executive 1.0beta. My guess is that your TestStand system is problem using the CVI 5.x runtime engine (CVI is required for many of our NI step types) unless you have installed a more recent version of CVI (or Measurement Studio) on your system. Have you? We could try installing the CVI 6.0 runtime engine.
Let me know what you find.
