The ReadMultipleItems is supposed to return when it has finished the work successfully or with failure, OR when it could not finish because of some timeout.

In the current ReadMultipleItems implementation, there is at least one timeout that is set to 100 seconds and cannot be changed. This implies that before these 100 seconds elapse, one cannot decide whether the method has (incorrectly) blocked or not.

Here is also one more observation from the developer:

There is a SOAP timeout that equals to 100 seconds and cannot be changed currently. This means that any "hang" detection should only deal with execution times longer than 100 seconds.

I am afraid that we cannot help your further unless we get a solution in which the problem can be reproduced on our side.

There is also a slight chance that it would also help if you can get the issue reproduced with the sample application we have provided AND you would send us the call stacks, but you have earlier written that you cannot do that.

Is you have already learned, calling TerminateThread does not resolve the hang issue anyway, AND it creates more issues in itself. And one of these issues is that it makes it impossible to troubleshooting the "hang" you claim.

So, remove the TerminateThread from your program. Then, run the test again, and if/when it blocks, capture the call stacks. Those that we have so far are unusable because of your use of TerminateThread in the program.

Regarding the "disposing of" an interface pointer to IEasyDAClient: Yes, it is proper to call UnsubscribeAllItems first, if you are subscribed to anything (if you are not, then it is not necessary). And, according to general COM rules, the code needs to call IUnknown::Release() the same number of times AddRef() has been called on the same interface. With your usage of the smart pointers (wrappers) in C++ code, this normally transforms to calling ClientPtr->Release().

I have received your source code.

Unfortunately, the code contains a call to TerminateThread. This is bad. See msdn.microsoft.com/en-us/library/windows/desktop/ms686717(v=vs.85).aspx . There are many problems with it, but here specifically, (quote from the Microsoft doc):

•If the target thread owns a critical section, the critical section will not be released.

This means that if you terminate a thread that is doing something and has acquired some locks, from that moment on nothing else in the program will be able too get pass that lock - and it will hang too. This can explain why in the call stack we have received from you, there is a thread that appears to be waiting on some lock for no reason (no other thread is running that owns the lock).

You must not call TerminateThread. Remove all its usages from your program.