After battling for half a day with that subtle bug, I am posting the workaround and analysis here, in case other stumble on it.
The issue lies with the TWICImage class, which encapsulates Microsoft Windows Imaging Component, and can be triggered in multi-threaded usage scenarios, particularly in services.
TWICImage interfaces with Microsoft Windows Imaging Component through a IWICImagingFactory interface stored in a class variable, which is initialized in TWICImage constructor, and there are three issues:
- The initialization logic is not protected by a critical section, and is not thread safe.
- TWICImage.Destroy clears that class variable once there are no more references, but that logic is not protected either, and not thread-safe.
- If TWICImage is created from a thread where OLE has not been initialized (with CoInitialize f.i.), the initialization will silently fail, and TWICImage will just bomb with an access violation at a later time.
The workaround for all three issues is rather simple: create a TWICImage in your main program or in the initialization section of a unit, and do not release it for the duration of the application.
Hi,
Is that addressed in upcoming 10.3.2 ?
If not, would you please provide these information to EMB and open a ticket for that, this may help solve this issue ASAP as the solution is somehow clear and very simple to implement due to your notes and description.
Thanks for sharing and also for the workaround.
No idea if it is addressed, I only have 10.3.1.
IIRC their issue tracker went dark a few years ago, and I do not even know where the EMB tickets are tracked these days as they got dropped off search engines.
As I checked the long list of fixed issues in new release, it seems this issue is not addressed and still persists.
Also I tried to find the issue-tracking strategy which is now used by EMB, with almost no success.
Thus tried to post a question, if I got the answer I’ll inform you.
Thanks.