Re: Tnslistener dying with 9.2 on Win XP Pro

> "szAppName : TNSLSNR.EXE szAppVer : 0.0.0.0 szModName : orantcp9.dll"
> "szModVer : 0.0.0.0 offset : 00005732"

This is not the normal type of Oracle error in the sense of a stuffed listener.ora file that can be fixed with admin traces and the like.

Pity the above error data is so brief.. but what seems to be happening is that the orantcp9.dll hits an exception of sorts.

To explain..

TNSLSNR.EXE is started. It loads a bunch of DLLs (dynamic link libraries providing various services). One of these is the orantcp9.dll.

By the sounds of it, this DLL is the Oracle TCP protocol adapter. I.e. it provides a standard networking interface for TCP/IP. You will find similar adpaters supporting the exact same interface for IPX/SPX, LU6.2 and so on. Very likely the orantcp9.dll in turn loads winsock32.dll (a system DLL) to use the TCP/IP socket interface on Windows.

One of two things are happening. The TNSLSNR.EXE passes "bad data" to orantcp9.dll and causes this DLL to crash and burn.

Or, the orantcp9.dll itself does something silly and causes itself to crash and burn.

We can assume that the TNSLSNR.EXE plays nice and pass the correct data to orantcp9.dll. After all the listener is a "mature" piece of software and its unlikely IMO that the call to orantcp9.dll got screwed (unless of course they have extended their protocol adapter API and screwed that up).

So that brings us to the orantcp9.dll and what it is up to... Debugging a DLL without the right tools is difficult. There likely are some error messages logged about this crash in the Windows Event Log.

How sure are you that the TCP/IP stack is correctly configured and working? Are you using Microsoft's TCP/IP blocking & filtering? Maybe proxy and firewall software?

I would stress test the IP stack first (I love to play around with ICMP floods ;-). Make sure that there are no problems there. Then I will muck about with the listener and make sure that it works (tnspings, starting and stopping, recreating the listener service, etc.).

Somewhere along the chain you should be able to isolate the problem and then hopefully identify and resolve it.

--
Billy