views:

193

answers:

1

I'm using Visual C++ 6.0. I'm not sure of the service pack level of the visual studio installation, but the OS is Win 2K SP4. The failing code is part of a DLL.

Here's the code:

EIO::OpenConnection()
{
    m_Client = new CSocket();

    if(m_Client->Create() == 0) {
        delete m_Client;
        m_Client = NULL;
        return CAsyncSocket::GetLastError();
    }

    if (!m_Client->Connect((LPCTSTR)m_IPAddress, 7)) {
        delete m_Client;
        m_Client = NULL;
        return CAsyncSocket::GetLastError();
    }

    ...<stuff>...
}

This compiles without error on my build system and executes without either of the calls to m_Client methods failing. When I move this DLL to the production system (Win 2K, not sure of service pack level yet), the call to m_Client->Connect() returns an error, so it goes into the IF block. CAsyncSocket::GetLastError() then the debugger to open and report an 0xC0000005 access violation. I don't understand this stuff enough to get anything out of the disassembly.

I've also tried CSocket::GetLastError() and m_Client->GetLastError() with the same results.

I'm fairly certain that m_Client->Connect() fails because of some security policy that's on the production machine that's absent on the development system, but I'd like to get the actual error code so I can help the IT guy narrow his search.

I haven't yet tried forcing a call to GetLastError() on my build system to see if I get an access violation there.

+1  A: 

The GetLastError() method most likely calls WSAGetLastError(). But for WSAGetLastError() to work, WSACleanup() must not have been called yet. I'm guessing that when you delete m_Client that exactly this happens. Try calling GetLastError() before you delete the m_Client object.

Stefan
Thanks, that did the trick. I started to suspect that might be the problem while I was sitting in a meeting after I submitted the original question.
aspiehler