teeChart6.ocx Hangs IIS in ASP application.

[Marc]

Hello cwdave,

We expect the AX update to be available this week. We'll post to this thread when it's ready for download from the customer download page. TeeChart AX7 7.0.1.1 already includes the updates made.

We can't predict all of the environmental factors when installing TeeChart to a Windows machine, partly because of the speed of change and availability of new software. TeeChart will continue to be supported in Windows for IIS and any new factors arising will be evaluated as they are known about. If the virus-scan software causes a problem and its continued running is required then a test environment could be setup to try to understand any problems.

Regards,
Marc

[Marc]

Hello,

TeeChart ActiveX v6.0.0.7 is available via the customer download page.

http://www.steema.com/downloads/client_access.html

Release notes:
http://www.steema.com/files/activex/pub ... se6007.txt

Regards!
Marc

[cwdave]

Many thanks for this patch. It's appreciated.

[SVMan]

Hi

In continuation of this issue, we had moved on to teeChart version 7.0.1.4. It looked like this new version seemed to have resolved the issue for some time. Recently the issue again has come up with version 7.0.1.4 with one of our customers and the same issue is happening.

The customer does not have any specific circumstances which trigger the hang. The problem is intermittent. They have installed IISState and have captured a dump of the w3wp process at the time of the hang. From looking at the dump the hang is a result of thread 17 holding a loader critical section and there is 14 other threads waiting on it. It appears that thread 17 is blocked trying to do some sort of Win 32 GUI operation (Send Message). teeChart appears prominently in the stack of thread 17.
Even the stack dumps look similar to the one we used to get in with Teechart version 6.

Please advise if you also have found this issue and if there is resolution for this in version 7.0.1.4 Also let me know if you need a copy of the stack dump.

Regards,

Ravi

[Marc]

Hello Ravi,

Are there any marked differences between the setup of the customer's server experiencing the problem and other or previous installations (eg. windows platform, IIS version, machine type, etc).

Are there any circumstances that force the error or under which the problem occurs with more regularity?

With thanks.
Regards,
Marc Meumann

[cwdave]

The customer is running Microsoft Windows Server 2003 (5.2.3790) - Service Pack 2. So they are on IIS 6.0. We are actively having them test different scenarios but have not yet turned up anything which seems to affect the frequency of the hangs. They only have the hangs in production.

Do you have any special kind of debbugging that can be turned on at the customer site? Or do you have a debug version of the OCX which they could register which could get us some more information about the hang?

Do you have an idea from the dump what the code path was through the OCX?

[cwdave]

More information from the customer on their environment:

Win 2003 Server Std Ed. SP2
IIS 6.0
Software installed
VantageView, COS, IBM TSM, Symantec AV, HP OVO agent, HP OVPerf Agent, CA Unicenter Job mgmt
Hardware
VMWare Guest - AMD Opteron 852, 2.60GHz 2GB mem

[Marc]

Hello,

We don't have a debug version of the TeeChart ocx that is likely to offer more information. We could look to prepare a test version with extra information if we can get a little nearer the problem area. Would it be possible for you to attach a part of the trace dump that you took and mentioned earlier in this thread?

The server appears to be low on memory for a production machine at 2GB. Please check whether any disk swapping is taking place. That kind of delay could cause problems for a request laden Chart in IIS. Extra RAM may help erradicate the problem.

Regards,
Marc

[cwdave]

Here is the stack trace from IISState this thread is currently blocking 14 or 15 other threads.

Thread ID: 17
System Thread ID: 17a0
Kernel Time: 0:0:42.828
User Time: 0:0:25.390
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\system32\TeeChart7.ocx -
Thread Type: Idle ASP thread
# ChildEBP RetAddr
00 0296f9a4 7739d1ec ntdll!KiFastSystemCallRet
01 0296f9e0 7738cee9 USER32!NtUserMessageCall+0xc
02 0296fa00 504fceb3 USER32!SendMessageA+0x7f
WARNING: Stack unwind information not available. Following frames may be wrong.
03 0296fa24 5042474f TeeChart7!DllUnregisterServer+0xbd033
04 0296fa4c 50424ab2 TeeChart7+0x474f
05 0296fab0 7c81a352 TeeChart7+0x4ab2
06 0296fad0 7c839e1e ntdll!LdrpCallInitRoutine+0x14
07 0296fbe4 77e6b1bb ntdll!LdrUnloadDll+0x41a
08 0296fbf8 77691d0f kernel32!FreeLibrary+0x41
09 0296fc04 77691d23 ole32!CClassCache::CDllPathEntry::CFinishObject::Finish+0x2f
0a 0296fc18 776bba27 ole32!CClassCache::CFinishComposite::Finish+0x1d
0b 0296fd7c 776bb97d ole32!CClassCache::FreeUnused+0x1bc
0c 0296fd8c 776c249c ole32!CoFreeUnusedLibrariesEx+0x36
0d 0296fd98 4a77bc30 ole32!CoFreeUnusedLibraries+0x9
0e 0296fd9c 7739b6e3 comsvcs!STAFreeLibTimerProc+0x6
0f 0296fdc8 7739cc95 USER32!InternalCallWinProc+0x28
10 0296fe40 7739bcad USER32!UserCallWinProc+0xf4
11 0296fea0 7739bad0 USER32!DispatchMessageWorker+0x138
12 0296feb0 4a77bde2 USER32!DispatchMessageW+0xf
13 0296fecc 4a77bcf2 comsvcs!CSTAQueueLessMessageWork::DoWork+0x4e
14 0296fee4 4a77c7de comsvcs!CSTAThread::DoWork+0x18
15 0296ff04 4a77cabf comsvcs!CSTAThread::ProcessQueueWork+0x37
16 0296ff84 77bcb530 comsvcs!CSTAThread::WorkerLoop+0x190
17 0296ffb8 77e6482f msvcrt!_endthreadex+0xa3
18 0296ffec 00000000 kernel32!BaseThreadStart+0x34

[cwdave]

Customer response regarding memory usage:
Right about now the memory util is around 57%, swap at 23%. I don't have the data leading up to the hang I just had now, but I should have it for the next case. We're limited in the amount of memory right now on this system due to VMWare 32bit restrictions. 2GB is the maximum.

[Marc]

Hello,

Do you have other installations running without problems on similar VMWare platforms? It may be a factor that we should reproduce in tests to try to recreate the problem.

With thanks.
Regards,
Marc

[cwdave]

Yes we have other installations running in VMware. We also use VM's quite a bit in our testing.

Do you know why the thread with teeChart in the call stack is blocked? Can you give some more indication about the changes that were made in response to this problem when we were running teeChart 6? I do remember a comment that programs like virus scanners could potentially make the problem worse. Our customer is reluctant to make the virus scanning changes which I have suggested. But I am pushing them on that.

[Marc]

Hello,

Re. Do you know why the thread with teeChart in the call stack is blocked?
Sorry I don't have the answer to that yet.

We are checking what work was done on v6 when this issue was originally reported to us. Changes will have been carried through to version 7 but we are confirming that no further change was made that might affect this kind of application. Have you tried version 6 at any stage on this customer machine? The possibility that a virus-checker might be causing problems is valid and certainly worth following up on.

Regards,
Marc

[cwdave]

I don't think we'll be able to try version 6. Too much customer impact. I'd also be concerned about loading a version 7 tee file with a version 6 ocx. The problem is only happening in the customers production environment.

[cwdave]

I asked the customer to try a test to revert from version 7.0.1.4 to 7.0.1.1 the following is their report:

• Good news. As I had previously stated that I would, I ended up applying the teechart7.0.11 file last Thursday at about 1-2pm. Since then we have not had any recurrence of the hang/crash issue of VantageView. In addition to that fact, it's been a high work-load week on Vantage View due to some major issues occurring, so it's been putting VV to the test. I am going to continue to monitor and hold in place right now, I am thinking for another week. By the end of next week I'd like to think that we're probably going to be in the clear for this situation finally since May. Whew. Here's hoping.