irs_recv kills IDA session. Any way to trap it?

R

roocoon

New member
Hello.
I couldn't find an appropriate section so I post here. Please move it to the right place if it doesn't belong.

Environment:
Windows 7 SP1 x64, using IDA 6.1.

Problem:
Debugging 64-bit plugins using IDA's x64 remote debugger on the same machine as the main IDA.
(Due to lack of hardware and debuggee requirements, I can't use VMs or run the remote debugger on another computer).

The above setup has been working in all cases for a few years, so it's not a configuration problem.
The last few months though, it stopped working, but only when run for a small set of (big) applications. For the remainder, it still works fine.

That points to something common to these specific applications.
A DLL (unlikely, unless it's hidden in the .NET infrastructure), a service (likely but disabling the ones I could identify didn't help), or a Windows DLL/service that is used by these applications and not the others.

The error is related to RPC or TCP/IP communications.
irs_recv: The wait operation timed out.

The sequence of processing is this:

1. IDA starts with some plugin's IDB loaded.
2. It then, either it starts the calling application or attaches to it.
3. In either case, it gets to the point where it rebases the plugin.
4. It finishes rebasing (that could take half a minute to more than an hour for the huge ones), it might go on until a few more plugins (related/unrelated to the debugged plugin), or just right away, throw out the "irs_recv" message and kill the session.

To make it interesting, sometimes it could even show a popup like:
"oops! internal error 40201" or some other number.

Being 64-bit programs, IDA can't be set as JIT as far as I know (assuming it would help) and the current Visual Studio JIT doesn't get activated by the timeout error (which makes sense since it's not a system-critical one).

Any TCP or Server timeout values I have identified and raised didn't help.

RPC tracing looks like a nightmare to get into (I tried and couldn't get anything useful out of it).

I even tried some suggestions from similar threads that dealt with problems running the Android remote server from Windows 7 (strict certificate requirements for the remote debug server), created my own certificates and resigned the relevant IDA modules, and still nothing.

Wireshark traces didn't help either (they might have had something in them but on a gig-sized trace file with no idea what to look for, it was a lost case).

Trying logging on as a different user (also admin) didn't help either.

So I'm stuck.
Has anybody come across this problem or has any suggestions on how to identify the module sending the timed out request?

Thanks in advance.
 
R

roocoon

New member
It happens on all plugins for this set of applications.
Anything out of this set of applications (programs, plugins and whatnot) can be debugged in 64-bit without hassles.

Ah yes, I can debug anything in the misbehaving set of applications if I run their 32-bit versions.
It's just their 64-bit that has a problem.
 
Storm Shadow

Storm Shadow

Administrator
Staff member
Developer
Ida Pro Expert
Elite Cracker
do you have some files you can uplaod to see if it happends to us also, or maybe we can try provoke the same error.
We can also try edit the code to continue as a last resort
 
R

roocoon

New member
That could be tricky.
Any plugin would cause the problem and they are easy to upload. Probably even the plugins that come with the application itself (but I never tried them to verify).
The hard part is uploading any of the main applications (easy to find on the net though). They are 2 gb + Autodesk behemoths. Things like Maya or 3ds Max.

Editing the code sounds good. I could try it on the spot.
 
R

roocoon

New member
Tell me about it :)
I don't have to debug those but rebasing a plugin for 90 minutes and then crashing, is bad enough.
Could the code you think can be edited, be controlled by some registry or environment variable related to timeouts?
I changed some but maybe I missed the right one.
 
Storm Shadow

Storm Shadow

Administrator
Staff member
Developer
Ida Pro Expert
Elite Cracker
i have to lookup the sdk. debugger code is pretty large :)
to bad it isent writing in Python.
 
computerline

computerline

New member
Ida Pro Expert
My system doesn't support x64, but if you want to patch time, I found it in win32_stub.p64, hope this help :)

BJ0KLeO.png
 
computerline

computerline

New member
Ida Pro Expert
Maybe you need to patch in win64_remotex64.exe too

Code: 
int __fastcall sub_140001500(SOCKET s, char *buf, int len, __int64, __int64)
 
sub_140001190 proc near                ; CODE XREF: sub_140001500+21p
.text:0000000140001190                                                                    ; sub_1400079F0+4Ap
.text:0000000140001190                                                                    ; DATA XREF: .rdata:stru_14008EFB0o
.text:0000000140001190                                                                    ; .pdata:00000001400A203Co
.text:0000000140001190
 
Storm Shadow

Storm Shadow

Administrator
Staff member
Developer
Ida Pro Expert
Elite Cracker
Could be anything


Code: 
earch "irs_recv" (8 hits in 6 files)
  C:\Users\z\Downloads\IDA65SDK\idasdk65\idasdk65\plugins\debugger\async.cpp (1 hit)
    Line 74: ssize_t irs_recv(idarpc_stream_t *irs, void *buf, size_t n, int)
 
C:\Users\z\Downloads\IDA65SDK\idasdk65\idasdk65\plugins\debugger\rapi\rapitest.cpp (2 hits)
    Line 33:    if ( irs_recv(irs, &rp, sizeof(rp), -1) != sizeof(rp) )
    Line 35:      printf("irs_recv: %s\n", winerr(irs_error(irs)));
 
C:\Users\z\Downloads\IDA65SDK\idasdk65\idasdk65\plugins\debugger\rapi\rapi_arm.cpp (1 hit)
    Line 20:  while ( irs_recv(irs, &rp, sizeof(rp), -1) == sizeof(rp) )
 
C:\Users\z\Downloads\IDA65SDK\idasdk65\idasdk65\plugins\debugger\rpc_engine.cpp (2 hits)
    Line 115:    code = irs_recv(irs, ptr, left, is_server ? -1 : RECV_TIMEOUT_PERIOD);
    Line 127:        dmsg("irs_recv: %s\n", winerr(uint32(code)));
 
C:\Users\z\Downloads\IDA65SDK\idasdk65\idasdk65\plugins\debugger\tcpip.cpp (1 hit)
    Line 85: ssize_t irs_recv(idarpc_stream_t *irs, void *buf, size_t n, int timeout)
 
C:\Users\z\Downloads\IDA65SDK\idasdk65\idasdk65\plugins\debugger\tcpip.h (1 hit)
    Line 53: ssize_t irs_recv(idarpc_stream_t *irs, void *buf, size_t n, int timeout);
i never managed to build the debuggers from scratch but you could try sdk 6.5 and change the protocol number from 17 to 14
 
R

roocoon

New member
Much appreciated for the help.

I don't think I have the stamina to build the debugger (or enough knowledge for this task), but I'll patch it and see what happens.

The timeout message is in 3 routines that I care about (ida.wll, ida64.wll and win64_remotex64.exe). The rest is for other platforms.
I had come across some sample code like you posted (in an old IDA SDK) and I was hoping to find out if that RECV_TIMEOUT_PERIOD can be overriden by some environment variable. Unfortunately it looks like it's not.

I'll try it sometime tomorrow and let you know of the results.

Regards.
 
R

roocoon

New member
Hats off to you people.

computerline's pointers were right on the mark!!

I started off by setting to maximum (0xffffffff) the couple of hardcoded timeout values in win64.remote64.exe.
(For some very optimistic reasons, IDA uses a default of 10 seconds. Either they have very fast and top of the line systems, or they don't load 64-bit programs with huge IDA databases that take upwards of an hour to load).

I started Max under IDA, it got to the point where it rebased the file, it loaded more than 100 extra modules (it used to crash after 3-4 of them), it attached eventually to Max, and right away I was back with the irs_recv error. Just when I was getting excited.

So I went back and also set to maximum timeout value the single reference in win32_stub.p64.

Back to Max and, at last, I was in business. It loaded just fine and I could debug without any problems.

Observations:
Right after Max finishes loading, with IDA in control, there's lots of disk activity and CPU usage of IDA and its remote server.
I suppose it transfers to it the stuff it needs.
Considering my system is pretty slow, free memory very low and my disk almost full (therefore fragmented), that could explain the long timeouts I was getting. After all they started a few months ago so maybe I had a cleaner disk up to then.

Well, I'm happy now. I can wear the old laptop down to its limits, and still use IDA.

Much obliged for your help.

Cheers.
 
You must log in or register to reply here.
Top