PDA

View Full Version : IDA x64 strange error

roocoon
February 19th, 2012, 19:36
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.
roocoon
August 25th, 2012, 03:15
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/ ("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.
Aimless
August 25th, 2012, 06:42
I do not get them if I DO NOT USE my remote debugger.

Have Phun
roocoon
August 25th, 2012, 06:52
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.
roocoon
December 31st, 2013, 14:49
"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:

Quote:
...
...
//#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?
zadow
February 5th, 2014, 14:44
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.
roocoon
February 5th, 2014, 15:02
Quote:
[Originally Posted by zadow;96111]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.

I have this already (I use Comodo and have the Windows firewall off) and had also uninstalled the firewall to try.
No luck.

In any case, it happens only with a specific set of programs. No problems with other x64 applications so it can't be the port or some IDA restriction.

I'll try the JIT approach though I think I had tried it a few months ago.

Thanks.
zadow
February 5th, 2014, 15:07
okay
You can try the remote version 1.15 http://filemare.com/en-no/browse/89.161.129.196 for ida pro 6.2/6.3/6.4
i see that there was a russian that had same error with remote gdb, but recompiling the armlinux_stub.plw helped him.

Quote:
IDA use for developing and debugging native code on android.
Detect problems when debugging Android.

Debugger does not connect. While another 2 days ago everything was ok.

Here Kartika from adb shell:
# / Data / tmp-p5000
/ Data / tmp-p5000
IDA Android 32-bit remote debug server (ST) v1.14. Hex-Rays (c) 2004-2011
Listening on port # 5000 ...
================================================== =======
[1] Accepting connection from 10.0.2.2 ...
Could not establish the connection
================================================== =======
[2] Accepting connection from 10.0.2.2 ...
Could not establish the connection

Here is what the IDA:
irs_recv: The wait operation timed out.
Command "ProcessAttach" failed
Command "ProcessAttach" failed

When this is done naturally redir (redir add tcp: 5000:5000) and telnet localhost 5000 works perfectly.

Recreate the emulator, made even rollback Windows on the date when everything worked, nothing helps.
gdbserver debugger connects fine, but you can not put bryakpoynty.

I do not understand what's wrong. 6 hours spent trying to understand and shamans. Who says that?

-------------------------------------------------- ---------------------
I answer myself:
All repaired. Perekompilit armlinux_stub.plw and was all ok.
The problem is that the localhost IP and had two of the first connection was impossible to vstoromu as possible.
A rpc_engine_t :: network_error_code reset to 0 only on the plugin is loaded. Inserted at the beginning of a connection reset and all was chudesnenko, polosatenkie and raspberry.

http://translate.google.com/translate?hl=en&sl=auto&tl=en&u=http%3A%2F%2Fexelab.ru%2Ff%2F%3Faction%3Dvthread%26forum%3D3%26topic%3D15481%26page%3D15&sandbox=1
roocoon
February 5th, 2014, 15:29
I found a few cases having to do with Android debugging. I tried similar fixes (resigning some IDA modules) but they never really fixed it.

I'll try the 1.15 remote and see what happens. Hopefully it will work properly with the IDA 6.1 I use.
roocoon
February 5th, 2014, 17:20
Too bad. The 1.15 remote is incompatible with IDA 6.1.
zadow
February 5th, 2014, 17:28
Yes it have a different protocoll. It works with the demo.well all debuggets from 6.1 do.
I would still look again at the firewall policy. Turning fire wall off also comodo.
Isent the same as the firewall policy rule as i mentionede before.
roocoon
February 5th, 2014, 17:38
Some of them could work with the demos but not the x64 remotes.
The demos don't include the idaq64 as far as I know.

The firewall policies are OK. I've even uninstalled Comodo and tried but still time out.
In any case, if it was a firewall problem, it would be a problem for all 64-bit programs I trace and not just a few.

Those RPC problems are a headache.
zadow
February 5th, 2014, 17:59
could it be the tcpip.cpp and tcpip.h


tcpip.h
Code:
#  define SYSTEM_SPECIFIC_TIMEOUT_ERROR ETIME

#include "consts.h"



idarpc_stream_t *init_client_irs(const char *hostname, int port_number);

bool name_to_sockaddr(const char *name, ushort port, sockaddr_in *sa);

void term_client_irs(idarpc_stream_t *irs);

void term_server_irs(idarpc_stream_t *irs);

void setup_irs(idarpc_stream_t *irs);

int irs_ready(idarpc_stream_t *irs, int timeout_ms);

ssize_t irs_recv(idarpc_stream_t *irs, void *buf, size_t n, int timeout);

ssize_t irs_send(idarpc_stream_t *irs, const void *buf, size_t n);

void irs_term(idarpc_stream_t *irs);

bool init_irs_layer(void);

void NT_CDECL term_sockets(void);

int irs_error(idarpc_stream_t *);

bool irs_peername(idarpc_stream_t *irs, char *buf, size_t bufsize);

bool irs_getname(idarpc_stream_t *irs, char *buf, size_t bufsize);



#endif


and
tcpip.cpp set the time in milliseconds

Code:
int irs_ready(idarpc_stream_t *irs, int timeout)

{

  static hit_counter_t *hc = NULL;

  if ( hc == NULL )

    hc = create_hit_counter("irs_ready";

  incrementer_t inc(*hc);



  SOCKET s = sock_from_irs(irs);

  int milliseconds = timeout;

  int seconds = milliseconds / 1000;

  milliseconds %= 1000;

  struct timeval tv = { seconds, milliseconds * 1000 };

  fd_set rd;

  FD_ZERO(&rd);

  FD_SET(s, &rd);

  int code = select(int(s+1),

         &rd, NULL,

         NULL,

         seconds != -1 ? &tv : NULL);

  if ( code == 0 )

    inc.failed();

  return code;

}


Code:
ssize_t irs_recv(idarpc_stream_t *irs, void *buf, size_t n, int timeout)

{

  if ( timeout != -1 && !irs_ready(irs, timeout) )

  {

    SET_SYSTEM_SPECIFIC_ERRNO(SYSTEM_SPECIFIC_TIMEOUT_ERROR);

    return -1; // no data

  }

  return qrecv(sock_from_irs(irs), buf, (int)n);

}


defently looks like some sort off socket error you got there.

both files have your warning included.
It could be anything that causes this.
Other software/conflicting varibles path.
Have you tried on a clean user. Admin one.
roocoon
February 6th, 2014, 00:48
The rpc_engine code I posted higher up also refers to the error.
One of them, or something like them that is still hiding, is the cause, but how do you fix it even if you're sure?
It should be adjustable by some TCP/IP timeout setting but still I can't find the right one (and I changed quite a few).
That's why I tend to suspect some 3rd-party task with a hardcoded timer (like some license server's timeout).
I disabled all I could but nothing.
No help from wireshark, etc and the RPC trace tools didn't show anything useful (but I probably don't use them to their full capacity -- too obscure for me).

I am an Admin but I haven't tried with another clean profile. I'll try it later today.