Just provisioned a new server running IIS and Server 2012 and SQL Server 2012. I also installed SQL Server Management Studio tool so I can quickly inspect databases without the need to open a remote connection.
When I browse an ASP.NET sites remotely, I get a Just-in-time debgugger exception dialog when an error is encountered in addition to the yellow screen. The dialog stays up on the server and piles up unless I RDP and manually close all the dialog boxes.
The only way to disable this is by removing Visual Studio Shell 2010 (integrated) using the control panel. The side effect is that I can no longer use SSMS.
Most of the available solutions are outdated or don't work. The registry settings are no longer applicable and most articles concerning this issue are old. Microsoft's official documentation is a rat's nest of broken links. Moreover, many users are confusing IE's script debugging dialog with this issue. Although they are related and similar, this specific issue is tied to Visual Studio's runtime environment.
Any ideas?
ASIDE: I can't believe Microsoft has this "feature" on a product that is installed on a production server. I am just floored by the incompetence of a multi-billion dollar corporation. I've seen my question asked since at least since 2005 with no official solution that works. I just have to ask one last time for sanity checking. I want to make sure I'm not the one who is "thick" in the head here.
To disable Just-In-Time debugging by editing the registry
In the Start menu, click Run.
In the Run dialog box, type regedit, then click OK.
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, delete the following registry keys also:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\WindowsNT\CurrentVersion\AeDebug\Debugger
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\DbgManagedDebugger
Take care not to accidentally delete or change any other registry keys.
Instead of deleting it, you can also just (temporarily) rename the AeDebug key for the bitness of your choice to something else, e.g. AeDebug-disable!
For server 2012, IIS, and SSMS 2014 we tried all three registry three deletions and those did not work.
What did work was old school renaming the JIT Debug executable.
Renamed these files.
C:\WINDOWS\system32\vsjitdebugger.exe
C:\Windows\SysWOW64\vsjitdebugger.exe
Renamed this folder
C:\Program Files\Common Files\Microsoft Shared\VS7Debug
As a follow-up to nfox's answer, I've created a registry file that you can simple use instead of searching manually through regedit.exe.
1.) Copy this script to your clipboard:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug]
"Debugger"=-
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework]
"DbgManagedDebugger"=-
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug]
"Debugger"=-
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework]
"DbgManagedDebugger"=-
2.) Save it to a file with the .reg extension:
E.g. to a file named
C:\Users\<user name>\Desktop\DisableJit.reg
3.) Double click the file
After confirming the appearing message box, the keys are getting deleted.
5.) Alternatively: Download file
If this is too much effort, you can download the registry file from here:
disable-the-just-in-time-debugger-windows-64-bit.reg
disable-the-just-in-time-debugger-windows-64-bit.zip (As a ZIP)
Download and then double-click it.
This tip was simply taken from the MSDN article "Just-In-Time Debugging in Visual Studio".
The syntax on how to delete registry keys via a .reg file was taken from the MSDN KB article "How to add, modify, or delete registry subkeys and values by using a .reg file".
You should be able to disable Jist-In-Time debugging using the Debug options dialog inside Visual Studio. The registry keys are also well documented here.
See:
http://msdn.microsoft.com/en-us/library/5hs4b7a6.aspx
Aside: I think it's not a wise thing to install a management studio on a production server. This is what management workstations are for. Remote connections from a management station can be pre-configured and stored so that it doesn't take much effort. That way you can keep your production environment clean.
Related
Running SSMS 18.6 causes the program to launch, hang, and then crash. There is no error message given, the program simply terminates before any action is taken and nothing is connected.
I've uninstalled and deleted all files for SSMS, Visual Studio, and SQL Complete.
I tried the 18.6 and 18.5.1 versions of SSMS to no avail.
From https://dba.stackexchange.com/questions/237086/sql-server-management-studio-18-wont-open-only-splash-screen-pops-up/237087#237087 :
I have tried copying the Interop.8.0.dll file from privateassemblies into public. No effect. The line in the config file mentioned here is already commented out in the recent release of SSMS.
From Sql Server Management Studio closes immediately after startup :
I have tried renaming or deleting the package file listed here and removed the relevant registry key. This causes SSMS not to open at all and Windows to issue an alert sound. No other effect.
From https://social.msdn.microsoft.com/Forums/silverlight/en-US/9d0e2459-eb74-46e8-a983-05ae2ba18977/ssms-crashes-on-startup?forum=sqltools :
I tried to repair .NET framework. No effect.
I was only able to install and successfully connect on SSMS version 17.9.1
I can provide Event Viewer details if anyone is willing to help me troubleshoot. I have a .NET Runtime error and two application errors- one is event name CLR20r3 and the other is APPCRASH. Happy to provide more information if needed.
While I can't speak to the exact reason it happened, I found a solution. Whatever the issue was, I discovered it was user specific and limited to my machine. Other users were able to access SSMS as normal on my machine as was I on theirs.
I happened to remember that the AppData folder exists and is just hidden, so I used an administrator account to copy that from a working user and rewrite the files in both of mine that were not used in some background process. This allowed me to once again access SSMS both as my regular user and with my elevated administrator account.
I had this same issue (it happened all of a sudden perhaps due to a windows update). I also tried all the other solutions listed above, but the only thing that worked for me was to uninstall and then reinstall version 7.9.1 like the original poster recommended.
In my case I only have 1 user on the computer, so the other user accounts being able to access was not applicable.
I created SSIS packages and used the Integration Services Deployment Wizard to deploy it out to the server. I'm manually going to the Integration Services Catalog access through SQL Server 2012 and right-clicking and executing my package.
However, the package keeps failing and I'm getting the following errors when I check the execution report's messages.
They appear to be failing on data tasks where I have script components.
Assign :Error: CS2001 - Source file 'C:\Windows\TEMP.NETFramework,Version=v4.0.AssemblyAttributes.cs' could not be found, CSC, 0, 0
Assign :Error: Failed to compiled scripts contained in the package. Open the package in SSIS Designer and resolve the compilation errors.
This answer is a more detailed version of UberDoodles answer.
In Windows Explorer.
Navigate to C:\Windows\Temp\
Right click the folder and select properties
Go to tab Security, choose Advanced
On the default tab Permissions, choose Change Permissions
For the relevant Permission entry, choose edit.
By default, I had 'allow' checked for Traverse folder / execute file, Create files / write data and Create folders / append data.
Also check 'allow' for List folder / read data and Take ownership.
Press OK, the window closes
Press Apply and confirm anything you need.
Additionally, the logged in user had already Full control, but when I changed this for the entry 'Users', it worked for me.
(based on microsoft file/folder permissions).
I had the same problem today, just on SQL 2016.
For me it helped to change the target server version in Visual Studio project properties from SQL Server 2012 to SQL Server 2016.
I was investigating the same issue, and I came across a solution here :
https://social.msdn.microsoft.com/Forums/vstudio/en-US/73e67f3a-c575-4c73-a71d-ed7a2aeabb50/csc-error-cs2001-source-file-cwindowstempnetframeworkversionv40assemblyattributescs?forum=msbuild
Basically, the account which the package runs under needs to have full permissions to the C:\Windows\Temp\ folder, so that it can create temporary classes.
It worked for me :)
I had the same problem. I first used Eric G. response and added the List and Read permission to the c:\windows\temp. After I got everything working I went back and removed that permission. I then redeployed my solution from Visual Studio, this time designating the deployment target as SQL Server 2014 (which was the environment I was using) using Martin's solution. I then reran the process, and it worked with the List and Read removed.
I kept it using Martin's solution, as I don't like to have special permissions granted if I don't need them.
Good Luck
[Visual Studio 2017 15.9.16]
I just restarted Visual Studio as Administrator and the issue disappeared, which confirms the permissions idea of the answers above but spared me all work.
It's not a quirk though, as per this question and its answer you need that kind of permission for several tasks, like profiling and debugging under certain conditions.
For the sake of completeness, this blog says you might incur in some security contraindication if run VS as administrator when opening third-party solutions.
I have a solution in Visual Studio 2013, where among the others I have also a Database project. This project contains some .sql written in T-SQL.
IntelliSence and Parse (SQL (on visual studio menu) > Parse) do not work. I have gone through this Troubleshooting guide and many question on SO, but nothing worked.
As I understand is something in project setting that I need to configure or some leftovers I need to clean.
Any suggestions ?
In brief
IntelliSence is enable
SQL CMD is Disabled
In SQL Server Explorer there is an entry (localdb)\ProjectsV12 containing my DB.
Other solutions opened on the same instance of visual studio work fine
ReSharper is installed but is not the issue (I also tried without it)
Note:
The solution (the one that has issues) was created in a previous version of Visual Studio.
Update 15/12/2015
After some digging I found out that the issue may has something to do with the .v12.suo file (which is located alongside with .sln file and is hidden). Copping this file from a similar solution (one that IntelliSence works) eliminates the problem.
Another workaround that it may help, is to go to the "Database Project" properties (right click on the project in Solution Explorer and then select Properties), on the Debug tab and press Restore Default in "Target Connection String". In my case this just changes the Initial Catalog= value to Database and like "magic" IntelliSence works again! (in some cases it may need to restart the Visual Studio)
After this even if I restore (using Edit) the "Target Connection String" to the previous values the IntelliSence continues to work.
I know how to add additional extensions to SQL Server Management Studio, to have them treated just like .sql files. But, when opening them, a new instance of Management Studio is created.
I also see numerous issues posted about double clicking on .SQL files and getting them to open in the existing instance of SQL server. This already works for me.
What doesn't work is the additional extensions I have added. I'm using .PRC. All of the fixes propose changing various registry settings, all which are related to the default .sql extension.
I don't see see how any of these fixes can be applied to make other extensions work or if there is anything else I can do to solve this?
EDIT:
What i've done so far...
Copied over all the same settings from [HKEY_CLASSES_ROOT.sql] to [HKEY_CLASSES_ROOT.prc].
Checked all the settings mentioned in the article on sql server central to fix this issue for .SQL extensions.
Configured SSMS file type .PRC with editing experience "SQL Query Editor".
I even tried creating a batch file to open the file for me:
"c:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\ssms.exe" /dde %1
Even the 4th thing I tried opens a new instance, although this is the same call that is configured in the registry for sqlweb.sql.9.0.
I resolved problem of opening PRC file by double click. I simply exported this key from regedit
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.sql
Modified this file to look like this
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.PRC]
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.PRC\OpenWithList]
"a"="ssms.exe"
"MRUList"="a"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.PRC\OpenWithProgids]
"ssms.sql.11.0"=hex(0):
"ssms.sql.12.0"=hex(0):
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.PRC\UserChoice]
"Progid"="ssms.sql.12.0"
And applied it over registry. The original PRC key I backuped and removed from registry before I applied that new keys. Now PRC file is opened by double click on PRC file in opened instance of SSMS.
But highlighting doesn't work still for me :(
You seem to be going through a lot of hassle to deal with your source control system. Have you considered making your source control system recognize a different extension for procedures, tables, views, etc. which will prevent you having to make these registry changes on every developer's computer?
.proc.sql -> stored procedure
.view.sql -> view
.fn.sql -> function
etc. etc. Surely your source control system can handle longer extensions that contain ., and now Management Studio will behave properly with all your file types.
Our local IT has our My Documents folder on a network path. This causes a problem from MSQL Server management studio as it saves it auto recovery information every 10 min it will lock up as its doing its save.
I found where VS2008 saved its setting but I can not find out how to change it out of My Documents for this. Does anyone know where that setting is located?
Unfortunately, at least for VS2005 and VS2008 (and I think for VS2010, but I haven't checked there), this cannot be changed from the system's "My Documents" folder. This is terribly annoying, I agree, as we have our My Docs folder set to a network share. When we're on VPN, the network connection is very slow, so the auto-recovery feature isn't instantaneous and blocks the UI.
I found this feedback on Microsoft Connect that indicates the inability to change the setting: Saving Auto Recover Information in Visual Studio 2008 SP1
There are few "alternatives." You could, of course, turn off Auto-Recovery, but that's not generally recommended. What I've ultimately decided to do is simply increase the time interval between auto-saves. This is found under Tools\Options\Environment\AutoRecover (in VS2008), which is the same place you would go to turn it on/off.
Of course, in SQL Server Management Studio, there is no Environment\AutoRecover section in the options. However, if we remember that SSMS uses the Visual Studio core (and we're comfortable with a bit of registry hacking), we can adjust the time interval for SSMS, as well.
VS uses a REG_DWORD value named "AutoRecover Save Interval" to store the number of minutes between auto-saves. Just add that value to the following key in the registry (this is for SSMS2008). I set mine to 60 because I don't usually do much super-critical work in SSMS, but you can set it to a value that suites you.
HKEY_CURRENT_USER\Software\Microsoft\Microsoft SQL Server\100\Tools\Shell\General\AutoRecover
I realize this isn't really a solution to the original issue, but I think it's at least a viable alternative.
As a follow up, with later versions of SSMS Microsoft did add Auto Recover settings in Tools > Options > Environment > AutoRecover.
I found recovered files on my machine at: C:\Users<MyUserName>\Documents\Visual Studio 2017\Backup Files\Solution1