So I have a solution (in Visual Studio, 2010) with two projects: ProjectA and ProjectB. ProjectA is just a test console application for ProjectB (which is a library I’m writing). I’m not sure if this makes a difference, but I’m running two instances of the application on startup:
if (arg.Length == 0)
{
Process.Start(new ProcessStartInfo("arcticus", "t"));
}
if (arg.Length == 0)
{
ConnectingNode();
}
else
{
ListenNode();
}
When I go to trace the program, there are random locations (and not always consistent) where when I try to step into (or step over), the application will just stop debugging and close completely with not messages.
The other instance (that I’m not debugging) of the application crashes, showing an error in the console window. The error thrown is just a result of having lost connection to the instance being debugged.
Both projects are using the default Debug configuration, and normally it can trace just fine. Is there any changes to the build configuration, or just the general method of testing that would help solve this problem?
Additional Info: The library uses async. sockets, with some usage of thread-pools too.
“the application will just stop debugging and close completely with not messages” –> this is the kind of behaviour i got when accessing data that belongs to another thread while ‘playing’ with thread/threadPool/Tasks/TaskFactory. To solve this i had to use only thread-safe objects and/or Invoke/BeginInvoke. I discovered along the way that in some case, code from process ‘A’ is considered belonging to process ‘B’ if that was B that raised, say, an event.
Not sure to be precise enough but hope that can help.