Firstly,my environment is VS2005, and I want to debug app in the wince6.0 device.
I use Mfc.
I can deploy fine (I have linked vs2005 with the device successfully) and run the forms application through network.
Problem: Debugging wont start. It locks up VS2005. It seems to deploy the app fine, then hangs. Eventually it has no response, and vs 2005 is dead.
A little help for me is very important. Thank you!
If a thread gets in a tight loop and starves the RNDIS session, you will lose your activesync connection. VS2005 may very well lock up in this case.
Things you could try:
Does your app run okay when it's not on the debugger?
Can you debug application on the emulator?
Can you debug a trivial app on your device? (just a main function and a printf, for example)
Re-install VS2005 and your SDK
Upgrade to VS2008
Related
It seems that there are issues with running and debugging Tizen .NET (Xamarin Forms) apps on Tizen emulators.
My environment is a Windows 10 machine, with the latest 2004 version. For development I tried both Visual Studio Professional 2019 (v16.6.2) and VS Professional 2017 (v15.9.24) with the VS Tools for Tizen extension.
I am able to deploy the application on the emulator however cannot debug, VS fails with the message Unable to start debugging. The system cannot find the specified file and in the console output I can see an the message [StdErr] error: cannot remove forward listener.
Does anyone have any idea? Is there some magical software combination that I can use to make this work or am I missing something?
I've experienced no end of troubles with Visual Studio Tools for Tizen. I nearly gave up today completely, I've spent weeks just getting it to partially work, and only a day or two of actual development, but finally figured out a few things that might be unique to my system or most likely are just missing in the documentation (which is not rare for Samsung at all).
First up, the emulator issue. I'm assuming you've been through the certificate manager and generated a Samsung certificate (make sure to have installed the extensions in the package manager, Samsung wearable extensions and Samsung certificate extensions then run through and create your Samsung certificate in certificate manager).
So now in the emulator manager try "right" clicking the specific emulator and select allow to install applications. It might now indicate it has installed a certificate. This is a good sign. Also i assume you know not to use HyperV (you can look up how to create a bootloader that can enable you to dual boot windows where HyperV can be disabled in one and enabled in your default).
Assuming that worked and you still can't debug i found that you may need to build the application (clean the build for good measure first - remember this - it can save you often if things don't work when you change something), then click Start without Debugging from visual studio. This should install the application to the device and launch it, fingers crossed. Now if that worked, and your application is now running in emulator or on device, you may find that future attempts now to debug it will work.
The final thing which has nearly made me give up is the update to my watch. It recently updated and i noted the new tizen version reported by the watch is 5.5. So naturally i went ahead and changed the api level to 5.5 and hey presto it all just seemed to work and i could continue as before, debugging and changing things happily. Then i uninstalled the application for a dry run and since then I spent a week trying to figure out why it will not reinstall the application on the emulator or the watch ( (it was a week ago i upgraded to api 5.5 and there were no issues, so that was way down the list of anything that could go wrong). I reinstalled etc, did the whole gamut of things all to no avail. At some point i got it working on the emulator but not the watch, finally today i have it working on both and don't wish to develop anything, i'm spent.
So that final issue was resoled by moving the projects back to api 4.0 and they would now reinstall on my watch and my emulator (use the Start without Debugging trick as well to install it first). Also (my fault - why it worked on emulator but not watch at some point) beware if you have one that is api 4 and one is api 5.5 - which i did while i was testing the above (one is a service the other the ui - they were at different api levels - that will not work on a device - but was happy on the emulator).
If none of that works for you, i'd advise give up, life is too short.
Cheers
just starting to look at the Cordova tools for Visual studio.
Creating a blank Cordova probject, I am able to run (F5 debug), for Android and IOS (emulators), and also x86 windows, but for either Any CPU or x64 I get the following error..
The Microsoft Visual Studio Remote Debugging Monitor (MSVSMON.EXE) does not appear to be running on the remote computer.
So I have seen mentioned elsewhere that VS (32 bit) needs to run the above for 64 bit debugging. I have no problems running and debugging a classic desktop WPF.
I have tried disabling both my firewall (Zone Alarm) and any antivirus (Avast), but made no difference.
Anyone have any ideas what the problem could be here (or how to diagnose)
Thanks in advance for any help!
I have this same problem. I use the same applications as you do, Zone Alarm and Avast. If I try to debug and get that error, disabling or stopping the programs do not help. You need to close VS and restart it with the offending apps already disabled, then you'll be able to continue.
I stumbled across this question because I am looking for a way to keep from doing this.
When i debug apps on windows7 using VS 2005, it's very slow. just general slowness. works fine on xp.
running outside of the debugger is normal. Even when i start apps outside the debugger then attach and debug it is normal.
im running VS 2005 in Vista compatibility mode.
Any idea what i can do to prevent slowness when debugging?
Seems like the problem happens periodically and is related to the amount and location of breakpoints set in the debugger. The problem can be worked around by attaching to the process after starting it.
For a complete solution, probably need vs2008.
When running the debugger about 50% of the time, Visual Studio 2010 freezes and also locks up my entire machine. I can't even get to Task Manager. Nothing works except my mouse will still move. The only way to recover is to hard boot the machine which takes about 15 minutes each time. I don't have anything else running on my machine at the time except VS, IE 8 (sometimes) and Outlook.
I am running Windows XP on a Lenovo T400 with 3G RAM
Has anyone seen this behavior? If so, how did you fix it?
Thanks,
Rhonda
You don't mention what language your app is but I have run into this with our C++/CLI application on occasion. To avoid it, I changed the Project properties / Debugger and specify "Native" or "Managed" explicitly for the debugger type. The default of "Auto" can get confused.
Also, if you use Application Verifier from Microsoft, I have had VS hang while AV was configured to verify our .exe. To avoid this, we have to launch the app under the debugger as "Native".
Recently, my coworker and I upgraded our development environment to Win7 x64 with VS2010 Pro. Our application is specifically targeted at x64 platform.
The problem we are encountering is during debugging, when attempting to step through the code (F10), at least 50% of the time VS will simply lock up the application being debugged. The IDE has the appearance of having pressed F5, but the application is not responsive and we have to force stop the application.
Our application is a Client (GUI) and a Server that communicate through .NET remoting.
This is starting to directly affect our productivity, so if anyone has any ideas what may be causing this, please let me know.
There is an outside chance that it might be the debug symbols loading. Check the status bar I think it tells you when the symbols are loading.
This may be a moot point, but have you installed the VS 2010 service pack 1?
There are various bugfixes related to debuggers included.
http://support.microsoft.com/kb/983509
I had a similar problem. it turned out that a higher level program had a different run-time library (multi-threaded debug dll), while my app was simply a multi-threaded debug. Once I converted mine to a multi-threaded debug dll, the freeze stopped happening.