I am having an issue with a WPF application I am building. All development files are located on a Network Drive. No, there is no option to move them to my development machine (I have a small SSD... no jokes please ;-)).
The issue I am having is getting VS to debug the application. I hit debug, and it goes through the build process, and just stops. I see a 'Build Successful" message in the status at the bottom, but that's it... no debugging happens, the application does not fire up, etc... Yes, the application works, I am able to verify simply by running the app from the /bin/debug location.
I have tried adding the:
<loadFromRemoteSources enabled="true">
to devenv.exe.config.
I have also tried the caspol stuff as stated in other posts (http://stackoverflow.com/questions/974612/edit-and-run-net-projects-from-network-shares) to enable FullTrust to -allcode, as well as the networked drive itself, and nothing changes.
Please help... I really need to be able to debug!!!
The answer was staring me in the face. for some reason all dev files are symlinks. I needed to enable FullTrust:
fsutil behavior set SymlinkEvaluation L2L:1 R2R:1 L2R:1 R2L:1
Related
Not to bore you, I'm gonna make long story short. Two machines, identical systems on them, identical programs (mostly). One has Visual Studio installed, one has ... uhmm, something else.
Sometimes when I try to install applications from let's say a CD, Visual Studio's Just-In-Time Debugger pops up, reports an "unhandled win32 exception in ..." and asks whether I want to debug using "New instance of Microsoft VIsual Studio 2010". If I choose Yes, it runs VS, if I choose No it closes the thing, and I'm back in Windows Explorer.
Which would be ok, except I know the application is perfectly all right, and this way I cannot install it (in this latest cast it was the client from my bank for internet banking and paying bills and such).
So, how do I get rid of that thing (just-in-time debugger)?
I don't want to uninstall VS since I'm using it daily, of course.
Edit 1 :: I tried disabling Just-In-Time debugging in VS's Tools/Options/Debugging/Just-In-Time, then unchecking all three checkmarks, but that just gave another error when trying to run the executable installation program.
An unhandled win32 exception occurred in autorun.exe [some number]. Just-In-Time debugging this exception failed with the following error: No installed debugger has Just-In-Time debugging enabled. In Visual Studio, Just-In-Time debugging can be enabled from ...
Check the documentation index for 'Just-in-time debugging, errors' for more information.
Very informative :/
Edit 2 :: The application runs fine on the other machine that doesn't have VS installed. To a large extent software on both machines is the same, with just some minor differences (systems installed from image). Minor differences: notepad2, ++, git, ... some small stuff that is left to dev's own choosing.
I don't want this to sound as rant against VS, since I realize it's taking that tone, but I extremelly dislike software that is not self contained and messes other software up. And I had the same problem before with other applications as well. So for now, I'm blaming VS.
If necessary, I'm willing to disable all kinds of debugging for this thing to work permanently (mostly use print statements anyways), if that will help. And if it possible.
I just had this problem today with Visual Studio 2013. This MSDN article:
Just-In-Time Debugging in Visual Studio works for me. In my case, I just rename Debugger to Debugger_del and DbgManagedDebugger to DbgManagedDebugger_del.
To disable Just-In-Time debugging by editing the registry
On the Start menu, search for and run regedit.exe
In the Registry Editor window, locate and delete the follow registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\DbgManagedDebugger
If your computer is running a 64-bit operating system, also delete the following registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\DbgManagedDebugger
Take care not to accidentally delete or change any other registry keys.
Close the Registy Editor window.
I am adding this response even though this is an old topic because I have just spent most of the day on this very issue and finally solved it. Every solution I found focused on disabling or turning off JIT debugging in Visual Studio, deleting keys from the registry or changing IE script debugging settings. But if you don't have a registered copy of VS, you have a problem. Of course, many of the solutions work in different ways but then you are left with the error above "no installed debugger has just-in-time debugging enabled" which no-one seems to have an answer for. However, the answer is not to disable JIT but rather stop server side debugging in your application. Unless you actually want to do server side debugging it is not necessary for it to be on.
It makes complete sense to me now because I had server side debugging turned on in ASP. Before installing VS, it made no difference because no debugger was assigned to handle the bugs so they were sent to the browser. Once I installed VS, JIT took over and did what tit was supposed to do.
So the quick answer, open IIS, click on default sites or your sites and in your application settings, ASP in my case, turn off server side debugging!!
It may not be everyone's answer, or even the solution to the above problem, but hope it provides more insight to this problem and help someone else.
regarding the key in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug and SOFTWARE\WOW6432Node\Microsoft, I could only change the Auto value from 1 to 0 and it worked.:
REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug" /v Auto /d 0
REG ADD "HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug" /v Auto /d 0
If you're running the same software on two machines and it's crashing on one(which is what's happening if the debugger is starting) then you probably have something else going wrong on your machine. It could be that you've got driver incompatibility issues, or that some of the other software you have installed on the machine has incompatible versions of dll's...
You need to try to eliminate as many of the differeces as you can (easier said than done, I know)... If you copy the contents of the CD onto a local disk, does that help? If you shutdown your virus checker while you install the software does that help? Does it help if you turn the network off? You've said that both machines have 'mostly' the same, software, what happens if you uninstall some of the differences? Have both machines been patched to the same level?
As Visual studio is trying to start up when you have issues, have a look at the call stack and see what dlls are loaded, print it out... run some of the other software that crashes on that machine and do the same thing... look for any common libraries and do a comparison between the machines to see if they have the same version of the libraries...
Of course it could also be that it's a hardware issue (I've had intermittent failures before now because one of my drives was getting ready to fail and others because my graphics chip was running too hot)...
As I said, not really an answer, but some things to consider...
If all else fails... you're probably stuck doing your bills on the other computer (although another experiment might be to create a VPC on the broken pc to see if it worked then)...
Right click on Project--Properties. Select the 'Web' tab. Under Debuggers, check 'Silverlight' (beside ASP.NET that is already checked).
Now visual studio won't debug your javascript because fortunately it can't debug Silverlight and javascript at the same time. You can now attach your javascript to the browser debugger.
This problem was appearing when I started pdf viewer. I reinstalled this program in other folder (another disc in comp) and in my case it worked.
I am having below mentioned issue when I am running Asp.Net MVC 2 project on windows Azure emulator (dev environment)
I have installed Windows Azure SDK for .NET - October 2012 version and I am using cache feature on my system.
With above error Below one is also comming.
How to get rid of this ?
Maybe I have an stupid solution, but that works with me.
When I begin to recieve the message "CacheInstaller.exe has stopped working", I do the following:
1) Stop the execution.
2) Go to the Role I'm using in the Azure project and open the corresponding Properties page.
3) Go to the "Caching" section and there I uncheck the "Enable Caching" checkbox. After that I checked again.
4) Save*, Run de application and never the warning appear again.
Is weird because nothing should change if you uncheck and check it again an option without save in the middle, but in this case when you do that the file changes (I can see it in the red icon that said something change there, :P)
I hope this helps. Cheers.
Do you have any error messages in the event log that may give more hint.
It could be an issue with missing dlls, do you have the windows server appFabric installed as well on this machine, which may be leading to a conflict with the dlls?
A procmon log might help you see what file paths its looking for.
"http://technet.microsoft.com/en-us/sysinternals/bb896645"
I banged my head against the wall on this one as well. I finally figured out the problem after digging deep into the crash-dump logs located within: C:\Users\{YOU}\AppData\Local\dftmp\Resources\{GUID}\directory\DiagnosticStore\AzureCaching\
AzureCaching does not allow UNC paths.
As my primary .net dev is from a vm, my documents/projects drive is mapped to my native drive located at: \\psf\Home\Documents\... Once I moved the project to the vm c:/ drive, CacheInstaller worked as intended.
Might as well post my experience as I was unable to locate anything on this specific problem.
I found today that if my system time was more than about 10 minutes wrong then CacheInstaller.exe bailed out on starting the emulator.
That includes the combination of system time and timezone being wrong, presumably as it results in an inability to calculate the correct UTC time at which Azure operates. Fixing the system clock resolved the issue in my case.
Not to bore you, I'm gonna make long story short. Two machines, identical systems on them, identical programs (mostly). One has Visual Studio installed, one has ... uhmm, something else.
Sometimes when I try to install applications from let's say a CD, Visual Studio's Just-In-Time Debugger pops up, reports an "unhandled win32 exception in ..." and asks whether I want to debug using "New instance of Microsoft VIsual Studio 2010". If I choose Yes, it runs VS, if I choose No it closes the thing, and I'm back in Windows Explorer.
Which would be ok, except I know the application is perfectly all right, and this way I cannot install it (in this latest cast it was the client from my bank for internet banking and paying bills and such).
So, how do I get rid of that thing (just-in-time debugger)?
I don't want to uninstall VS since I'm using it daily, of course.
Edit 1 :: I tried disabling Just-In-Time debugging in VS's Tools/Options/Debugging/Just-In-Time, then unchecking all three checkmarks, but that just gave another error when trying to run the executable installation program.
An unhandled win32 exception occurred in autorun.exe [some number]. Just-In-Time debugging this exception failed with the following error: No installed debugger has Just-In-Time debugging enabled. In Visual Studio, Just-In-Time debugging can be enabled from ...
Check the documentation index for 'Just-in-time debugging, errors' for more information.
Very informative :/
Edit 2 :: The application runs fine on the other machine that doesn't have VS installed. To a large extent software on both machines is the same, with just some minor differences (systems installed from image). Minor differences: notepad2, ++, git, ... some small stuff that is left to dev's own choosing.
I don't want this to sound as rant against VS, since I realize it's taking that tone, but I extremelly dislike software that is not self contained and messes other software up. And I had the same problem before with other applications as well. So for now, I'm blaming VS.
If necessary, I'm willing to disable all kinds of debugging for this thing to work permanently (mostly use print statements anyways), if that will help. And if it possible.
I just had this problem today with Visual Studio 2013. This MSDN article:
Just-In-Time Debugging in Visual Studio works for me. In my case, I just rename Debugger to Debugger_del and DbgManagedDebugger to DbgManagedDebugger_del.
To disable Just-In-Time debugging by editing the registry
On the Start menu, search for and run regedit.exe
In the Registry Editor window, locate and delete the follow registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\DbgManagedDebugger
If your computer is running a 64-bit operating system, also delete the following registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\DbgManagedDebugger
Take care not to accidentally delete or change any other registry keys.
Close the Registy Editor window.
I am adding this response even though this is an old topic because I have just spent most of the day on this very issue and finally solved it. Every solution I found focused on disabling or turning off JIT debugging in Visual Studio, deleting keys from the registry or changing IE script debugging settings. But if you don't have a registered copy of VS, you have a problem. Of course, many of the solutions work in different ways but then you are left with the error above "no installed debugger has just-in-time debugging enabled" which no-one seems to have an answer for. However, the answer is not to disable JIT but rather stop server side debugging in your application. Unless you actually want to do server side debugging it is not necessary for it to be on.
It makes complete sense to me now because I had server side debugging turned on in ASP. Before installing VS, it made no difference because no debugger was assigned to handle the bugs so they were sent to the browser. Once I installed VS, JIT took over and did what tit was supposed to do.
So the quick answer, open IIS, click on default sites or your sites and in your application settings, ASP in my case, turn off server side debugging!!
It may not be everyone's answer, or even the solution to the above problem, but hope it provides more insight to this problem and help someone else.
regarding the key in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug and SOFTWARE\WOW6432Node\Microsoft, I could only change the Auto value from 1 to 0 and it worked.:
REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug" /v Auto /d 0
REG ADD "HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug" /v Auto /d 0
If you're running the same software on two machines and it's crashing on one(which is what's happening if the debugger is starting) then you probably have something else going wrong on your machine. It could be that you've got driver incompatibility issues, or that some of the other software you have installed on the machine has incompatible versions of dll's...
You need to try to eliminate as many of the differeces as you can (easier said than done, I know)... If you copy the contents of the CD onto a local disk, does that help? If you shutdown your virus checker while you install the software does that help? Does it help if you turn the network off? You've said that both machines have 'mostly' the same, software, what happens if you uninstall some of the differences? Have both machines been patched to the same level?
As Visual studio is trying to start up when you have issues, have a look at the call stack and see what dlls are loaded, print it out... run some of the other software that crashes on that machine and do the same thing... look for any common libraries and do a comparison between the machines to see if they have the same version of the libraries...
Of course it could also be that it's a hardware issue (I've had intermittent failures before now because one of my drives was getting ready to fail and others because my graphics chip was running too hot)...
As I said, not really an answer, but some things to consider...
If all else fails... you're probably stuck doing your bills on the other computer (although another experiment might be to create a VPC on the broken pc to see if it worked then)...
Right click on Project--Properties. Select the 'Web' tab. Under Debuggers, check 'Silverlight' (beside ASP.NET that is already checked).
Now visual studio won't debug your javascript because fortunately it can't debug Silverlight and javascript at the same time. You can now attach your javascript to the browser debugger.
This problem was appearing when I started pdf viewer. I reinstalled this program in other folder (another disc in comp) and in my case it worked.
Using Visual Studio 2010 on Window 7 64bit. I'm trying to test a website project (not a web application project) using the built in dev server (cassini). The problem I'm having is that when I make a change, I now have to actually stop debugging, kill cassini, and restart before I can actually see my changes in the browser. I used to be able to edit and refresh. One of my fellow developers here is able to do this just fine with an identical setup (same project/vs version/os - and settings near as I can tell). I'm beginning to suspect some sort of permissions issue. I've been all over google trying to find an answer to no avail. Any ideas?
As it turns out, this was my fault... I had experienced the dreaded "network BIOS command limit has been reached" issue. I found a post that recommended doing a regedit hack "HKLM\Software\Microsoft\ASP.NET\FCNMode = 1", well this basically turns off File Change Notifications. Changing this value to 2, and applying the changes recommended in knowledge base 810886 fixed both problems.
I'm sorry if I'm asking the wrong thing in stackoverflow, but I've come to my wits end dealing with Blackberry. Documentation, site organization, general levels of support have all come together to the point that I haven't been able to do a whole lot of actual work in this environment.
I currently have the Eclipse environment downloaded from the blackberry developer's area website. I can run the simulator and everything else without issue. What I'm trying to do now is to move from debugging on the simulator to debugging on the device itself. This is an important step for me, but I haven't found a satisfactory way to do it...
What I've found are some posts saying that I should package an ALX (of which I'm still not sure on how to do), and using the BDM to install it. This, however, means I won't be able to use the debugger...
If someone could direct me to a resource that will give me step by step instructions from coding to release of blackberry development, this would be awfully helpful.
Thanks so much!
Yes, please test your code on a device. Basic stuff works the same between both, but especially when you get into networking, media, etc. the devices are different.
You can debug on your device through Eclipse. I can't provide you with an end-to-end guide on SO, but here's the quick debug guide.
Build (sign if necessary) and load your app onto the device. You can do this with the desktop manager, or with the command-line javaloader tool that comes with the JDE (look in the bin directory), or even OTA (over the air)
After loading, make sure the Desktop Manager is NOT running (it'll interfere with on-device debugging)
From Eclipse, create a new debug configuration, in the Debug Configurations dialog click on BlackBerry Device, and then click on the new configuration icon. Default settings should be fine.
Make sure your device is plugged into your USB port and start your new debug configuration. You'll probably get a lot of prompts about things missing (because actual devices don't have debug info for any built-in stuff, generally) but click through those and you should be fine to debug.
This is something we struggled with a lot at my old company. I don't think it's possible to do with Eclipse, you have to use the BB JDE, creating the necessary project files against the same code base. I could be wrong on that one as we weren't using the RIM Eclipse plugin, just building it all with Ant.
Personally I never managed to get passed "debugger attaching..." on the device, although I believe a colleague got it to connect but found it too slow to be usable (if you think how slow the emulator can be sometimes...). I know our ant build file had a target for building a version specifically for the JDE profiler, although that was only against the emulator.
In the end we resorted to using our own function debugging code that manually logged entries, exits, parameters and run times, sending the result to a special server.
Sorry if that doesn't help much, but that was our experience.
Never needed to debug on the device itself, I've always found that the apps i've written work on the device, same as on the handset.
As for generating an ALX, in eclipse right click on the project inside the Package Explorer and select "Generate ALX File".