Results 1 to 14 of 14

Thread: IDA x64 strange error

Hybrid View

  1. #1

    IDA x64 strange error

    Hello.

    I hope somebody can explain the following IDA behaviour and suggest some solution.

    This refers to IDA 6.1 running under Win7 x64. (No problems at all in 32-bit).
    When I trace some 64-bit program (with lots of modules), most of the time I get one of the following error popups:

    "oops! internal error 40208"

    or

    "irs_recv: The wait operation timed out."

    If I use IDA 5.5 x64 instead, the message becomes:

    "rpc event protocol error"

    This is clearly a communication timeout but I have no idea where it comes from.
    Only topic on it I found, pointed to armlinux_stub.plw which shouldn't apply to my case.
    Also the title of an unreachable link refers to rpc_debmod.cpp which again should not apply.

    Nothing in the system's event log and nothing obvious in IDA's log.
    No blocking by the firewall and no difference if I disable the network controller.

    It could relate to the module I'm modifying of course (but why IDA crashes?) but again I don't see anything.
    No TLC in the module, I break when it loads and while I just look at it, I get the comms error.
    The fact that it doesn't happen all the time, complicates it a bit.

    I checked all the .NET Frameworks in the system and they are clean and properly registered.

    What else could I be missing?

    Thanks in advance for any pointers.

  2. #2
    I'm bringing this alive again.
    I must say I find it surprising that nobody came across the irs_recv errors (or they did and didn't bother to comment maybe).
    It should be a pretty common error if you debug 64-bit code.

    Some related discussions about debugging cellular software, brought me to this:

    http://social.msdn.microsoft.com/forums/en-US/windowscompatibility/thread/179b7738-d9fe-40fb-9014-f05f3cbfb34b/

    Most of the errors disappeared after I signed IDA's debug server.

    I still get them here and there but it could be some other piece of code (maybe non-IDA related) that has to be signed.
    Unfortunately I have no way to find which one it is (there are dozens of loaded plugins on the platform I debug).

    Anyway, I hope the above helps somebody.

  3. #3

    As Above

    I do not get them if I DO NOT USE my remote debugger.

    Have Phun
    Blame Microsoft, get l337 !!

  4. #4
    I know. Me neither.

    But how can you debug 64-bit without remote debug? Even with the debug server running on the localhost (which is also considered 'remote'), the problem is still there.

  5. #5
    "irs_recv" returns!

    This problem I've been having for some months, came back pretty soon after the initial improvement when I resigned the IDA remote server and a few other files.
    I can't tell if it's some Windows update that reverts something, so I decided to try and fix it some other way.

    According to the error message "irs_recv: The wait operation timed out" (and assuming the message is the proper one), some handshake times out.

    I have no way to live trace with wireshark or anything else since the error happens after IDA code rebases that take way upwards of 30 minutes to over an hour and a half. I doubt my laptop could even handle the generated log.

    Looking for "irs_recv" I came across rpc_engine.cpp in the IDA v6.1 SDK that had some related piece of code in it:

    ...
    ...
    //#define DEBUG_NETWORK

    #ifndef RECV_TIMEOUT_PERIOD
    # define RECV_TIMEOUT_PERIOD 10000
    #endif
    ...
    // receives a buffer from the network
    // this may block if polling is required, then virtual poll_events() is called
    int rpc_engine_t::recv_all(void *ptr, int left, bool poll)
    {
    ssize_t code;
    while ( true )
    {
    code = 0;
    if ( left <= 0 )
    break;

    // the server needs to wait and poll till events are ready
    if ( is_server )
    {
    if ( poll && poll_debug_events && irs_ready(irs, 0) == 0 )
    {
    code = poll_events(TIMEOUT);
    if ( code != 0 )
    break;
    continue;
    }
    }
    code = irs_recv(irs, ptr, left, is_server ? -1 : RECV_TIMEOUT_PERIOD);
    if ( code <= 0 )
    {
    code = irs_error(irs);
    if ( code == 0 )
    {
    code = -1; // anything but not success
    }
    else
    {
    network_error_code = code;
    dmsg("irs_recv: %s\n", winerr(uint32(code)));
    }
    break;
    }
    left -= (uint32)code;
    // visual studio 64 does not like simple
    // (char*)ptr += code;
    char *p2 = (char *)ptr;
    p2 += code;
    ptr = p2;
    }
    return code;
    }
    ...
    irs_recv has a timeout value as the last parameter:
    ssize_t irs_recv(idarpc_stream_t *irs, void *buf, size_t n, int timeout);

    RECV_TIMEOUT_PERIOD has an expected default of 10000 milliseconds.

    It looks like, if I could increase this timeout value, say to -1 for infinity or something pretty big, I could get by this error (assuming it's RPC-related).

    The question is how to do that so it affects IDA itself?
    Can I override the value with some environment variable or some registry tcp/ip setting, or do I have to find and fix it in some of IDA's dlls?

    I raised HKLM\Software\Policies\Microsoft\Windows NT\RPC\MinimumConnectionTimeout DWORD to 1c20 (7200 secs = 120 minutes)
    and lowered HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\KeepAliveTime DWORD to 493e0 (300000 mils) (5 minutes)
    but it made no difference.
    (That might be because the keepalive setting is ignored by the system unless it's explicitly set up at a higher level than tcpip).

    Any suggestions for a solution?

  6. #6
    i got the same errors about an year ago. not spesific irs_recieve but debug rights.
    i would do Run > WF.msc
    new rule
    both inbound/outbound port spesific 23946.to be sure you get free acces for the port.
    You could use just in time debugger also within ida.

Similar Threads

  1. strange AntivirusXP2008?
    By evaluator in forum Malware Analysis and Unpacking Forum
    Replies: 4
    Last Post: August 6th, 2008, 23:56
  2. Help about such a strange SEH trick
    By kcynice in forum Advanced Reversing and Programming
    Replies: 16
    Last Post: June 4th, 2008, 11:52
  3. Found something strange..
    By malikah in forum The Newbie Forum
    Replies: 6
    Last Post: June 29th, 2007, 15:22
  4. Another strange packer
    By Cthulhu in forum Malware Analysis and Unpacking Forum
    Replies: 2
    Last Post: April 3rd, 2007, 07:23
  5. Very strange behaviour
    By Firestream in forum Bugs
    Replies: 3
    Last Post: January 15th, 2003, 10:34

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •