Strange Ants problem: win32-recv fails using LineLevelTiming

SamJost

I'm using Ants Profiler 7.4 Standard to profile a .NET executable (mixed c#/c++/clr application) and encounter a very strange problem:

When I start the problem standalone it works as it should.
When I start it using Ants and use Sample method-level timings it works, too.
But when I use Line-level and method-level timings I get an error when using tcp/ip-Connections regarding this win32 api:


int PASCAL FAR recv (
__in SOCKET s,
__out_bcount_part(len, return) __out_data_source(NETWORK) char FAR * buf,
__in int len,
__in int flags);

When some legacy part of the app uses this win32 api recv the call will fail with the error: WSAENOTSOCK 10038

Socket operation on nonsocket.
An operation was attempted on something that is not a socket. Either the socket handle parameter did not reference a valid socket, or for select, a member of an fd_set was not valid.

So for some strange reason line-level timing messes up my application communication.

Is this a known problem and a workaround?

I just upgraded Ants to the most current version 7.4 without any changes (the problem also existed on version 6). The system is x64 Windows 7.

Kind regards,
Sam

Chris.Allen

I don't recall this particular error or even any general interference with tcp/ip however, it is known that the instrumentation technique (line/method level) of profiling is much more "interfering" than sampling method when it comes to the running of IL since it dynamically injects IL.

Does it help by locking out this part of the code to mulitple threads (if only to test)?

Brian Donahue

APP installs detours for Win32 socket functions, so blocking calls can be noted in the results. Could this have something to do with the problem?

SamJost

Chris.Allen wrote:

Does it help by locking out this part of the code to mulitple threads (if only to test)?

So I can lock this part out (exclude it) from profiling? I found no option in the "new session"-dialogue to achieve this.

Brian Donahue wrote:

APP installs detours for Win32 socket functions, so blocking calls can be noted in the results. Could this have something to do with the problem?

The recv should block until it receives data instead of throwing an error, so it might have to do something with the problem. I just don't see how to work around this.