| Title: | TeamLinks for Windows |
| Notice: | Kit and ECO locations: See replies to note 8. o note 8. |
| Moderator: | ORION::chayna.zko.dec.com::tamara::eppes AN |
| Created: | Mon Aug 28 1995 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 2238 |
| Total number of notes: | 9650 |
My customer have a serious problem in Teamlinks 2.7. Very randomly, a PC gets a GPF in module X400. But the only error I can see in the CFCDEBUG.LOG file is a XTIDNW: Internal error - Network I/O recursion detected. at the last line. Customer is running WFW with Pathworks 6.0 client and WIN95 using MS-TCP/IP. The last lines in CFCDEBUG.LOG says: Function: 57 (UnlockObjectId) Session: 0x10000003 Resource: 0x20000009 (A1MAILFC) Object Id: 0x23B7617A CONNECT: FlushConnectInfo () Closing session: 0x10000001 Ending SPI session: 0x20000001 (A1MAILFC) SPI session: 0x23B70E40 XTIDNW: Internal error - Network I/O recursion detected. XTIDNW: Internal error - Network I/O recursion detected. Any hint.... /Torben [Posted by WWW Notes gateway]
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 2228.1 | XANADU::CUMMINGS | Jerry Cummings, TeamLinks | Mon Jun 02 1997 11:37 | 4 | |
Can you provide any more info about what actions the
user had just performed prior to this?
Jerry
| |||||
| 2228.2 | Thats all | NNTPD::"[email protected]" | Torben Sorensen | Tue Jun 03 1997 10:57 | 10 |
I am sorry, I can not get more information about this error, since the user sees GPF in Teamlinks often each day. So what happens at this particular situation is unknown. But in generel, this customer sees alot of GPF in module X400. Best regards, Torben [Posted by WWW Notes gateway] | |||||
| 2228.3 | Network recurrsion | XANADU::FLANAGAN | Tue Jun 03 1997 15:53 | 36 | |
Torben,
The recursion error in XTI results from a call into an XTI*.DLL while a
previous call is still in progress. In this case it is the XTIDNW.DLL
which means DECnet was in use although it could be reported by
XTIWINS.DLL when TCP/IP was the transport.
The UI normally prevents any user actions which would cause a second
NetWork I/O call but apparently there's still a few unguarded paths.
Unfortunately they must be pretty obscure, since in most cases the UI
will simply beep and put up a message after three such user attempts.
One workaround is to type slower:) since if the network operation
completes before the next request there won't be any recursion.
You could revert to the V2.5 behavior of not dispatching window
messages by setting two values in win.ini
[XTI Transports]
BlockingHook=1
and
[RDASL]
NoYield=1
but that prevents the screen from repainting and isn't recommended.
Most of these problems have been fixed, but there are apparently a few
still around - perhaps when using an integrated app. If you can give
us more details we can try to find that errant path.
/ Peter
| |||||