why would an application acts differently after VS debugger is attached?

Question

There is a desktop application written in c# trying to manage a socket connection and failing but being successful after same application is attached to visual studio.

how can it be debugged?

Answer 1

Usually, timing issues. Are there threads involved? If C/C++, then there could be a lot of reasons because of how memory management bugs might behave.

Answer 2

You might have variables whose default values are different when running under the compiler as opposed to standalone. Race conditions might be another idea if there are threads involved.

If you are allocating RAM via malloc or new, then make sure that the memory is initialized properly before using it.

Answer 3

I'd say timing issues too having the debugger attached will slow down the code slightly which might mean that a race condition isn't occuring.

To debug it try to add some logging code to your application, I personally use log4net

You shouldn't have and problems with malloc and the like as you are coding in c#.

if you are running a web app it might also be there is a difference in the cassini webserver in VS and the one you are deploying to.

Answer 4

This is a classic example of timing.

If it works in the debugger then it means you have to re-factor your code a bit to handle this.

Now if you are app is a server socket that receives connections from client and trying to spawn a thread for each of those connections, you might have to consider using select() to manage connections with in one thread.

Answer 5

We've actually encountered a similar issue. Timing is a critical part of this. As well as throwing no-ops into the code (primary difference w/ debugged code).

With socket programming, it seems as though debugging w/ VisualStudio.Net is like having additional Application.DoEvents() calls made. We have found that we have stuff that will fail (non-debugging) unless we allow the component to breathe (e.g. handle its own events) by calling Application.DoEvents().

Answer 6

When Visual Studio attaches to your application, the CLR and JIT have subtle runtime differences to enable debugging. Garbage collection for example is different.

http://stupiddumbguy.blogspot.com/2008/05/net-garbage-collection-behavior-for.html

Answer 7

IT might be because you're watching properties with side effects in your debugger. Though the other answers here are more likely...