Breakpoints causing connection loss on debug

Breakpoints causing connection loss on debug

• kmazur

  Just to let you know, I am using the Composite UI Application Block, which adds a bit of complication into debugging the loading of the modules that compose my application.
  
  I have found a particular module that will cause a connection loss if breakpoints are used. This will only occur if all 3 modules composing my application are deployed and loaded (I'm guess some sort of memory problem). I have verified that I can step into the application using F10. The weird thing is, I will not lose a connection if I step through the CAB module loading process. Everything will load and run perfectly fine if I step through the process. If I hit F5 to run through it, the connection will drop every time and the application will close. There is no single line that I can narrow anything down to since stepping through the code works just fine. If I remove the offending breakpoint, the application loads and runs fine.
  
  
  

• Riyadh Calling

  I'll go ahead and join in on this thread. I am the developer on NETCF responsible for managed debugging.

  Reading through the above it sounds like you have evidence for quite a few different symptoms and they are not very deterministic. Let me verify that we have this all correct.

  1) If the full app is present on the device, you start with F5 -> sometimes disconnects if breakpoint is set anywhere, sometimes disconnects if breakpoint is set on specific modules but not others, sometimes works properly, always works properly when no breakpoints are present

  2) If the app is fully present on the device, you start with F10 -> never disconnects irregardless of number and location of breakpoints

  3) If the app is partially present on the device, you start with F5 -> sometimes disconnects if breakpoint is set anywhere, sometimes disconnects if breakpoint is set on specific modules but not others, tends to work properly more often then if the full app was deployed, always works properly when no breakpoints are present

  4) If the app is partially present on the device, you start with F10 -> never disconnects irregardless of number and location of breakpoints

  Unforetunately I can't draw any good conclusion from that yet. The top options I see at this point would be to use the native JIT debugger as Srinivas suggested to gather info on the app when it crashes or, if acceptable to you, to let us reproduce the issue here with a copy of your application. Thanks for helping us out with this,

  Noah Falk

  .Net Compact Framework

  
  

• adorer

  Since the question is in C#/VB forums I am assuming you are htting the issue while doing managed debugging.

  So now my suspect is on two things. Either the app itself is crashing in debug due to the set break points on the device or edm.exe is crashing. The latter case is remote.

  Can you use the remote process viewer and let me know at the time of crash

  If the managed app is running on the device still AND

  If edm.exe is running on the device

  
  

• DotNetDave

  Hmmm, I've tried removing and reinstalling Visual Studio, ActiveSync, and .Net CF to no avail. I'm not sure what else I can try reinstalling (aside from a complete format, ouch).
  
  

• JCJCJC

  1) Are you able to repro this on any other machine if you have access

  2) Refer http://blogs.msdn.com/srini/ and use the device JIT debugger and let us know the module that is crashing (if it is) when the managed application is getting terminated on the device.

  3) I am getting in touch with NET CF Team to see if we can have any other clues.

  Thanks for your patience here.

  
  

• DaveRogers

  If the crash is in the native part of the managed application you should be seeing

  An unhandled exception

  was raised in "exe path +name"

  (process id = xxxxxx)

  To debug attach with

  Visual Studio

  To terminate, click OK.

  Post that you can native attach to the process from the VS on the desktop.

  If you are not seeing the JIT dialog then perhaps the crash is in the managed part. Let us know how it comes along on the other machine.

  
  

• arkiboys

  Looking forward for your replies. This might be a serious issue and we would want to nail it down and fix ASAP.
  

• haba

  Your points describe my problem perfectly. I am still in the process of getting another computer set up to see if this problem is reproducible elsewhere. I've set up the JIT debugger as per Srinivas's instructions, however, when the app crashes during debugging nothing additional happens. What additional information should I expect
  
  

• ChineduLB

  Hmm... I assume you don't have access to platform builder's native debugger either Without any additional information I would be entirely shooting in the dark trying to fix this problem. These are the next options I can think of:

  1) You haven't commented one way or another on whether this is acceptable to you, but if it is we could attempt to reproduce this issue here using a copy of your program.

  2) We could try to verify that JIT debugging is working correctly on your device by writing a trivial native app that does something bad, like dereferencing NULL. If JIT debugging is working properly you should see that popup Srinivas refered to and it would imply whatever is going wrong here is not the result of a crash from native exception. If JIT debugging is not working properly then we might be able to troubleshoot that and then return to the original problem.

  3) I will check if there is any internal diagnostic tool I am allowed to provide you. (Sadly there is a good chance I would be prevented by various legal or support issues but I will give it a shot)

  4) You could use a network traffic sniffing tool such as ethereal to capture the communication between debugger and debuggee. This isn't nearly as good as the native debugger but I should be able to reverse engineer the communication and probably narrow down what is going on based on how far the communication has proceeded before it is disconnected. Still no guarantee this would actually reveal the source of the problem.

  5) We could log this bug and hope that in the future we are able to solve it. I know this isn't the desired outcome but if there is no more diagnostic information available this is likely what will have to happen.

  I will followup with you on #3, but it is up to you if you would like pursue any of these other options. Also maybe Srinivas will have some other options I am not aware of As always thanks for helping us out and sorry to have you running into these issues,

  -Noah Falk

  .Net Compact Framework

  
  

• Francois vdv

  Just tested on a separate machine with a fresh installation of all software. Exactly the same problem. I'm not able to to get any JIT information. Keep in mind the ONLY way I can get this problem is when I attempt to debug the application from Visual Studio. And the only error message I get is the "The remote connection to the device has been lost. Please verify the device connection and restart debugging." message. I'm at a loss on how to get more information about this.
  
  

• RavensAngel

  If your APP is not having any legal/NDA issues can you share the app and the repro for us to figure the issue

  You are suggesting that a lot of customers are hitting this issue. To my information I just heard from one other customer so far.

  If this is being hit by everyone then it needs to be addressed ASAP.

  Let me try to understand the repro a little bit. Answers to below queries would be helpful.

  Set one break point and then do an F5. Connection to the device is lost. Right Also I am ssuming this is happening only for the big app and cannot be reproed for simple console apps etc.

  Is the application you are trying managed(C#, VB) or native(C++)

  What happens if you do a F10 to start the debugging Does it stop in the main entry point or does it lose connection right away

  I strongly suspect the device debug monitor (edm.exe) is crashing on the device due to some memory layout issue of setting the breakpoint. Let me send you logging instructions to confirm this.

  
  

• KeeperMustDie

  I apologize for the delay in responding. This is a fairly large application, and the problem grew worse with size. If I do not deploy the entire thing, I can usually use breakpoints, but often the connection problems begin and I have to remove them. If the entire app is deployed, I cannot set ANY breakpoints (usually) or the connection dropping occurs. Once the app is deployed and running, I can then set breakpoints and debug normally.
  
  This is a managed C# application, and when the connection problem occurs the application definitely shuts down on the device.
  
  Also, it's not entirely consistent in which breakpoints will cause the crash. I might be able to set breakpoints in one module, but ANY breakpoints in another module will cause a crash. Of course sometimes, these rules don't hold. For instance today, I'm having trouble getting any connection problems with breakpoints.
  
  I will continue testing today until I can reproduce it, and then try to get you more info.
  
  

• João S. B.

  Thanks for your time with this.
  I'm still looking into the feasibility of sending the source code.
  
  Attempting to enable remote attachment shows that I don't have the registry key AttachEnabled in
  HKEY_LOCAL_MACHINE \SOFTWARE\Microsoft\.NETCompactFramework\Managed Debugger. Under Managed Debugger I have another folder named Managed Process List whose key is named 3454251214. Do I need to create the AttachEnabled key
  
  Edit: After creating the key above, I was able to attach and debug. Though, since my application doesn't crash when run from the executable, I'm not sure how this helps much.
  
  Update: Now that JIT debugging is properly set up, I DO get an option to attach and debug when the crash happens on running from VS. However, the process is grayed out in the process list (presumably because I'm already attached to it since I ran it from VS ).
  
  If I understand JIT debugging correctly, I would run the application from its executable on the device and upon crashing, I would have a chance to attach the VS debugger to the process to step through the problem. My application, however, runs perfectly fine when run from the executable even when completely deployed. It is only when I'm debugging from within VS that the crash and connection loss occurs. And it is only if I have breakpoints in certain places and only if I use F5 to run the application. Ctrl-F5 to step through the startup works without a hitch and then once I'm past the critical section in which I'm loading my dlls can I hit F5 to finish starting up.
  
  I've copied eDbgJit.exe to \Windows on the device and ran a simple application that causes a NullReferenceException, although I still don't see any mention of debugging in the error dialog...only Quit and Details.
  
  I will try to capture network traffic information with Ethereal and see if this holds any more info.
  
  

• Mike Greenway

  Hi,

  I had this very same problem some time ago. I can only guess that the reason was various installations and removals of various .NETCF versions on the development machine for testing. At some point it gave me exactly your problem. The only cure was to reinstall the complete development environment. To be clear: The problem was not somthing with the code to be debugged, the problem was due to an installation mess on my machine.

  Cheers

  Andreas

  
  
• Breakpoints causing connection loss on debug