Steema Central

[Using TeeChart6.0.0.4]

In an IIS WebApp, several dozen ASP pages include a function called display_chart(), which is called once per chart that needs to be rendered in the browser's html.

Inside display_chart() a teeChart object is created, initialized from a bin BLOB via the LoadFromStream call. The BLOB is in a node selected from an MSXML2.Document.4.0 object that is instantiated from a physical .xml file that is unique to each ASP page. The node is typed as "bin.base64", and is accessed via the objDomDocument.nodeTypedValue property.

In a situation where more than one browser requests one of these ASP pages AT EXACTLY the same time, IIS deadlocks (no CPU activity) at the point of the LoadFromStream call. The problem occurs more frequently in IIS6, but has also appeared often in IIS5.

In an attempt to debug the problem, and remove MSXML totally from the scenario, the bin BLOBs were manually converted to .tee files and placed in a common directory. Then the code was modified so that the XML was ignored, and the LoadFromFile call was used instead of LoadFromStream. Yet the result was exactly the same, an IIS deadlock.

An IISState stack trace always shows the same profile; many threads waiting, a thread that is executing the teechart.ocx is hung, trying to call dll!unregisterserver. There is also always another thread whose call stack appears corrupt, but is consistent in that it is calling USER32!CreateWindowEx. Clearly, this should never happen server-side, right? Here is an example of the typical profile from the IISState trace...


Thread ID: 18
System Thread ID: 18c
Kernel Time: 0:0:24.187
User Time: 0:0:3.390
*** WARNING: Unable to verify checksum for C:\WINDOWS\system32\TeeChart6.ocx
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\system32\TeeChart6.ocx -
Thread Status: Thread is in a WAIT state.
Thread Type: Other
# ChildEBP RetAddr
00 0256e5bc 77f43741 SharedUserData!SystemCallStub+0x4
01 0256e5c0 77e41817 ntdll!ZwWaitForSingleObject+0xc
02 0256e630 77e4168f kernel32!WaitForSingleObjectEx+0xac
03 0256e640 5042f869 kernel32!WaitForSingleObject+0xf
WARNING: Stack unwind information not available. Following frames may be wrong.
04 0256e664 50448adc TeeChart6+0xf869
05 504411c4 504465f4 TeeChart6!DllUnregisterServer+0xadb0
06 50445e24 006ad88b TeeChart6!DllUnregisterServer+0x88c8
07 f0c48353 00000000 0x6ad88b

Thread ID: 19
System Thread ID: 7c8
Kernel Time: 0:0:22.375
User Time: 0:0:2.484
Thread Type: Other
# ChildEBP RetAddr
00 025ad8e4 77d0cfc4 SharedUserData!SystemCallStub+0x4
01 025ad9b8 77f4c22d USER32!NtUserCreateWindowEx+0xc
02 0000000e 00000000 ntdll!bsearch+0x7f


We have tried numerous workarounds (such as trying to use an Application.Lock around the LoadFromStream call), but to no avail. Our App depends on the Import.LoadFromwhatever calls as it is now architected, and we would like to retain that technique of loading chart configuration information. But, the only thing that works so far is hard-coding the Chart configuration directly into the ASP page. Then, even during simultaneous access, IIS does not deadlock. Clearly, that is a major overhaul, if it is the only workaround.

We continue debugging and testing and are hopeful we will catch a break and find a viable workaround. Can Steema, or a Steema customer reproduce this problem? Thanks (in advance).

We have a candidate workaround. It is being tested now. I took the LoadFromwhatever call up into an ActiveXDLL COM object that is single-threaded. That way, only one ASP can call it at a time. I tried a similiar technique using Application.Lock in the ASP page itself, but it did not work because I think the ASP were executing on the same thread (an IIS6 enhancement, if you catch my drift). So far so good, stay tuned.