WinBatch Tech Support Home

Database Search

If you can't find the information using the categories below, post a question over in our WinBatch Tech Support Forum.

TechHome

IMAPI

Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.

Problem Closing MsftDiscRecorder2

 Keywords:  

Question:

Does anyone know how to close this object?
oRecorder = ObjectCreate("IMAPI2.MsftDiscRecorder2")
Windows 7 x64. winbatch 2010A

100% of the time, no matter what I do, winbatch cannot kill that object in W7x64, and a winbatch.exe *32 process is left running (and in some instances locking files).

None of these 2 line programs work:

oRecorder = ObjectCreate("IMAPI2.MsftDiscRecorder2")
followed by any of the following:
oRecorder = ""
oRecorder = 0
oRecorder = ObjectType("dispatch",0)
These names don't exist:
oRecorder.close
oRecorder.quit
oRecorder.exit
Anyone know how to kill this object?

Try it. Run:

oRecorder = ObjectCreate("IMAPI2.MsftDiscRecorder2")
oRecorder = 0 etc etc
and check whether the winbatch.exe *32 process is still running.

Answer:

You may have to give VBS a try. WinBatch is doing exactly what it should but MSFT's object is causing a thread deadlock in the RPC system when WinBatch tries to unload dlls. MSFT likely tested the Automation server with VBS but never checked it against any clients that use the more complex WinBatch approach.

Alternatively, you could feasibily create an all WinBatch solution that would use one WinBatch process to kill the other. However, given the this is some kind of MSFT Windows bug involving a deadlocked theads in a process, such a solution may have undesirable side effects.

To be clear, this is not a WinBatch bug. We know exactly the point at which the WinBatch passes control to the Windows kernel during process shutdown. Shutdown processing is hung on what appears to be a thread deadlock during the COM uninitialization processing. This in turn is caused by some threading issue in the implementation of the imapiv2 objects. This problem will likely not go away (other than some kind of scripting workaround) until such time as MSFT decide to do something about it .

VBS was suggested as a workaround because it is quite likely that MSFT tested there COM object implementation with VBS so, assuming sufficient testing, it should work with same. The idea being that VBS could be used to perform the COM processing as a process forked from a main WinBatch script and not as a mechanism for killing the WinBatch process.

Killing the WinBatch process may be a perfectly safe thing to do as the Windows kernel tends to be robust and fault tolerant these days. But given the nature of the problem there is always some possibility that killing a process hung as the WinBatch process appears to be can lead to seemingly unconnected instability in the system later on. As remote as this possibility may be, it would be negligent to not at least mention it.

On the other hand, if killing the WinBatch process appears to solve the problem without any untoward side-effects then you have your workaround.

We will continue to monitor this issues and thanx for bringing it to our attention.


Article ID:   W18080
Filename:   Problem Closing MsftDiscRecorder2.txt
File Created: 2012:11:26:09:55:06
Last Updated: 2012:11:26:09:55:06