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?
_________________
Brian Donahue
Technical Support
Red Gate Software Ltd.
44 (0)870 160 0037 ext 8521
US and CAN 1-866-RED GATE ext 8521

[SamJost]