I have been busy today with finding a strange deadlock problem between IBM Client Access (pcsfe.exe and pcsws.exe) and an application of my current customer. Somehow "pcsws.exe" was waiting in "pcsfont.dll" for something when our software was running. Closing our application made "pcsws.exe" responsive again...
I have been busy today with finding a strange deadlock problem between IBM Client Access (pcsfe.exe and pcsws.exe) and an application of my current customer. Somehow "pcsws.exe" was waiting in "pcsfont.dll" for something when our software was running. Closing our application made "pcsws.exe" responsive again...
After a lot of digging and trying, I found out I had to kill one specific thread (thanks to ProcesExplorer) in our application to make pcsws working again. But what was so special on this thread? So I tried ProcesHacker (which gives even more information about processes etc than ProcesExplorer!) and I noticed I could right click on a thread and get all windows of this thread (!).
Strange, it had 2 (hidden) windows: "ADODB.AsyncEventMessenger" and "IME". After some googling I found this great blog articles that explained a lot:
http://marc.durdin.net/2012/08/waitforsingleobject-why-you-should.html
http://marc.durdin.net/2012/08/why-does-switching-languages-hang-my-app.html
It seemed it had to do with that fact I created the first(?) ADO database connection inside a thread. ADO then automatically makes the 2 hidden windows. When an other application does some kind of global keyboard layout or language change, Windows sends notification messages to all (!) windows. But because I did not do any message processing in my thread (because I did not need to), my 2 stupid hidden windows did not respond...
But at last, I found out that our application indeed made the first database connection inside a thread in some (timing) specific situations at startup (initialization of stuff). After forcing some initializations in the main thread, the 2 hidden windows did not appear in my thread anymore and the IBM locking was gone...
Well, that was a very instructive and productive day...NOT :(
After a lot of digging and trying, I found out I had to kill one specific thread (thanks to ProcesExplorer) in our application to make pcsws working again. But what was so special on this thread? So I tried ProcesHacker (which gives even more information about processes etc than ProcesExplorer!) and I noticed I could right click on a thread and get all windows of this thread (!).
Strange, it had 2 (hidden) windows: "ADODB.AsyncEventMessenger" and "IME". After some googling I found this great blog articles that explained a lot:
http://marc.durdin.net/2012/08/waitforsingleobject-why-you-should.html
http://marc.durdin.net/2012/08/why-does-switching-languages-hang-my-app.html
It seemed it had to do with that fact I created the first(?) ADO database connection inside a thread. ADO then automatically makes the 2 hidden windows. When an other application does some kind of global keyboard layout or language change, Windows sends notification messages to all (!) windows. But because I did not do any message processing in my thread (because I did not need to), my 2 stupid hidden windows did not respond...
But at last, I found out that our application indeed made the first database connection inside a thread in some (timing) specific situations at startup (initialization of stuff). After forcing some initializations in the main thread, the 2 hidden windows did not appear in my thread anymore and the IBM locking was gone...
Well, that was a very instructive and productive day...NOT :(
Comments
Post a Comment