When I use Visual Studio 2015 to debug a website, using file -> open website... on my local development database, queries slows right down to the point where they take a minute or more instead of milliseconds. Similar queries run by hand using SQL Server Management Studio (SSMS) are slow while Visual Studio is running.
SQL Server instance is running on the same machine as Visual Studio environment.
Here is what I've tried:
Stop Debug mode
After stopping debug, kill IIS Express process
Disabled IntelliTrace
Close solution in Visual Studio
The issue still persists after the above, and the problem is resolved when Visual Studio is shut down or a different solution is opened.
I checked the sql connections from SSMS and the connections were cleared once IIS Express process. It appears to be some sort of integration that Visual Studio is instrumenting with SQL Server libraries that is at the root of this.
Anybody have an idea what this might be or how to troubleshoot this further?
This issue was memory related. If the host that runs SQL server is strained for memory, SQL server will still operate but will bog right down to the point of being essentially inoperable.
My solution was to upgrade my system so that I had a ton of RAM and gave the VM running SQL server and Visual Studio tons of ram. This has the unfortunate side effect of taking for ever to suspend the VM but at least its SQL server is usable with Visual Studio.
I still don't know how to detect by looking at SQL statistics or process monitors. I guess I may need to find/open a new question to drill into this.
Related
I have an ASP.NET web application, and certain operations execute 6 times slower in the full fledged IIS 8.5 on the server versus in Visual Studio's IIS Express.
If I'd try to attach for just debugging I properly see w3wp.exe:
I cannot see w3wp.exe in the Profiler's Attach dialog.
I'm running VS 2017 with Administrator privileges. This is not a remote debugging scenario, both the full-fledged IIS and the debug tools are on the same server (a Windows Server 2012 R2 Essentials if that matters). I'm using Visual Studio 2017 Community Edition.
How can I debug my application in the IIS so I can figure out why it's 6 times slower there? It stuns me because usually it's the other way around: debug and profile versions are much slower than release ones.
Our server BTW is very memory limited. There are two developers working simultaneously and the 16GB physical memory (not upgradeable unfortunately) is topped easily. So I guess the regular IIS is in a memory squeeze by all the developer tools, SQL Server, etc. That might be a reason for slowness, but I don't want a guessing game, I'd like to see a profile session. Profiling VS's IIS Express was super easy BTW. If I see it correctly Visual Studio 2015 didn't even offer the profiling of a Running Process.
Rob was quite terse. First, you need to start Visual Studio in Administrator mode. Besides selecting ASP.NET as Analysis Target in the beginning, once the Profiling Wizard comes up on Page 2 you have to yet again select "An ASP.NET application" instead of your available project, otherwise Visual Studio just fires up a server. After that on Page 3 of 4 I specify the web URL of the application running by my local (non developer) IIS server (http://localhost:8000). Here you have to restart VS in Admin mode if you haven't done so. Then the Performance Output looks like if VS started another server:
Preparing web server for profiling.
Profiling started.
Launching web server with profiling.
Profiling process ID 872 (w3wp).
Starting data collection. The output file is C:\Users\Csaba\Documents\MyProjectSrc\http_localhost_8000__170924.vspx
Profiling process ID 8416 (iexplore).
Attaching to process 8416.
Profiler stopping.
Stopping data collection.
Merging collection data. Please wait...
Data is saved in file C:\Users\Csaba\Documents\MyProjectSrc\http_localhost_8000__170924.vspx
Profiling finished.
After the data collection I saw some spurious errors int he Event log stating that the collection won't be successful. Seemingly it was able to collect data from 3rd party library. But I cannot guarantee it's 100% legit because I didn't examine it thoroughly this time.
Choose "ASP.NET" instead of "Running Process..." when choosing the analysis target.
I was running into some issues trying to run the Profiler (especially since windows home edition doesn't have the full IIS Set by default)
Since you are running Visual Studio 2017, It might be a lot easier to run the new diagnostics tool instead.
The Diagnostics tool is located under
Debug->Windows->Show Diagnostic Tools
It provides the Cpu Analysis and Memory Analysis just like the analyzer does.
You can set a breakpoint and analyze a small section of the code as well.
I am working with an ASP.NET web application written in C# deployed to IIS/Windows Server 2008 R2. The application uses NHibernate to interact with an Oracle database running on a networked unix server.
It seems that writes being made by the application to the database have no effect.
If I manually edit the value of a record in the Oracle database, the new value is reflected by the application. However, if I attempt to change a value using the application’s custom “save” functionality, the changes are not reflected in the database. It seems like reads are succeeding, but writes are failing.
Why do writes seem to be failing?
More information:
No obvious error messages are received (ie. the application does not throw an exception and it seems to continue running as if everything is fine).
Another instance of this application is running on IIS/Windows Server 2003. This instance can write to the Oracle database (ie. the changes can immediately be seen in the database by using a database viewer after clicking “save”).
The code is virtually identical between the 2003/2008 applications. However, on the 2008 server, I am using newer versions of Oracle libraries and I changed to target architecture of the visual studio projects from ‘Any CPU’ to ‘x86’ (the 2008 server is 64-bit while the 2003 server is 32-bit).
Disclaimer:
I have very limited experience working with IIS, NHibernate, Oracle databases, Windows Server 2003, and Windows Server 2008 R2. I do, however, have slightly more experience working with C#, ASP.NET web applications, Visual Studio, and MSSQL databases).
I solved it.
It turns out one of the HttpModules was not being initialized. This was because the web.config file was tuned to IIS6, and the application was running in an application pool set to Integrated Pipeline mode on IIS7. Switching the application pool to Classic mode essentially enabled backwards compatibility.
Anyways, here is the resource that helped me figure it out: httpModules not working on iis7
We have a Windows Server 2008 R2 box setup as a Terminal Server with Visual Studio 2012 installed on it for remote developers to be able to do development on our ASP.net systems.
We would like to be able to do debugging on out projects the same way we do when developing on our local machines using visual studios internal development server.
I am trying to start local debugging on an ASP.Net project (F5) in VS2012 - the project compiles - IE comes up with my localhost url and then it just spins with "connecting..." and the page never comes up.
Pulling up the same workspace on a local machine and debugging comes up just fine.
I've exhausted my google-fu on looking for solutions here and humbly ask you all for any insight.
Visual Studio works a little differently when you are debugging on a server. You don't really want to use VStudio to play/debug on a web server. You need to use the menu option "Debug", "Attach to process". There will be several processes running, so it might take a few tries to find the right process.
Be careful though. Because your break-points will actually freeze IIS for the entire server. It could be a pretty big inconvenience for everyone who is using IIS at the time.
If you are trying to debug the project from your IIS server, you need to verify if the account has Administrator rights, also if the project has been deployed with its source files, you can attach the process (maybe it is w3wp.exe) in Visual Studio and debug it.
Another way is to open the solution using Visual Studio and change in the web project's property the server: Use Visual Studio Development Server.
Let me know more info about your scenario to provide you more paths.
What I would do is attach to the IIS process on the server: http://msdn.microsoft.com/en-us/library/vstudio/3s68z0b3.aspx you can even do this off your machine.
make sure debug is enabled in web.config for that app and you've mounted the remote project. Add a break point, debug by attaching to the IIS app pool process & it'll trigger the break point.
I was able to Attach Process to the SPUCWorkerProcess.exe even though it's a farm solution and not a sandbox solution
We have an ASP.NET application written in Visual Studio 2003 (c#) using SQL Server 2000 as database. It’s an old web application that our clients have been using for 4+ years.
Now, we needed to upgrade the application to work on Windows Server 2008 using SQL Server 2008, both 64bit, both on the same machine. So we ported the application to Visual Studio 2008, made some needed modifications and successfully installed the application on Windows Server 2008 with database still being the old SQL Server 2000. Everything worked fine. But as soon as I modified the connection string to work with the new SQL Server 2008 64bit, it stopped working. Basically the web browser just shows – The webpage cannot be displayed; no error messages whatsoever.
I monitored the processess and event log - basically it seems that asp.net worker process is generating errors until it stops working. And I can’t figure out why. All should be fine on SQL Server 2008 side, all protocols enabled, even disabled firewall; i can connect to the instance using Management studio from the same server (64bit) and from other development machines (64bit/32bit).
Then i tried using the web application from my development machine (still Vistual Studio 2003 one, i.e. 32 bit with ASP.NET 1.1) and connect to the new SQL Server 2008 and i got „Server application unavailable“ error. Same thing happens, worker process is generating errors until it stops working.
I used IIS Diagnostic Tool to debug the moment the error occurs – all i got was basically unlimited numbers of „First chance“ exceptions (problems with msvcr80.dll, mscorwks.dll). If I limited the number of those, I also managed to get „Kernel32!TerminateProcess“ exception, which after analysis stated that it didn’t detect any problems with that; only one time i got the warning, describing that 1 client connection was executing for more than 90 seconds.
I dont think the problem is on the 64bit Windows server 2008 or SQL server 2008 side, since when, just for checking, we used Sharepoint application with the new SQL Server 2008 as database, it connected just fine.
So what am I missing with our ASP.NET application configuration/development that it cannot connect to 64 bit Sql server 2008?
Thanks and regards,
Martin.
This sounds like a configuration problem, probably a permissions problem. Your Sql Server is on a different box than the your web server? If so I would look at what user your web site is running under. Make sure that user has access to the Sql Server.
If your user does have access make sure it has access to travel the wire to your SQL Server. Try to connect to the SQL Server via Sql Management Studio with the user's credentials.
So, I've read that it is not a good idea to install VS2008 on my test server machine as it changes the run time environment too much. I've never attempted remote debugging with Visual Studio before, so what is the "best" way to get line by line remote debugging of server side web app code. I'd like to be able to set a breakpoint, attach, and start stepping line by line to verify code flow and, you know, debug and stuff :).
I'm sure most of the answers will pertain to ASP.NET code, and I'm interested in that, but my current code base is actually Classic ASP and ISAPI Extensions, so I care about that a little more.
Also, my test server is running in VMWare, I've noticed in the latest VMWare install it mentioning something about debugging support, but I'm unfamiliar with what that means...anyone using it, what does it do for you?
First, this is MUCH easier if both the server and your workstation are on the same domain (the server needs access to connect to your machine). In your C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger\x86 (or x64, or ia64) directory are the files you need to copy to your server. There are different versions between Visual Studio versions, so make sure they match on the client and server side. On the server, fire up msvsmon. It will say something like "Msvsmon started a new server named xxx#yyyy". This is the name you'll use in Visual Studio to connect to this server. You can go into Tools > Options to set the server name and to set the authentication mode (hopefully Windows Authentication) - BTW No Authentication doesn't work for managed code.
On the client side, open up Visual Studio and load the solution you're going to debug. Then go to Debug > Attach to Process. In the "Qualifier" field enter the name of the server as you saw it appear earlier. Click on the Select button and select the type of code you want to debug, then hit OK. Hopefully you'll see a list of the processes on the server that you can attach to (you should also see on the server that the debugging monitor just said you connected). Find the process to attach to (start up the app if necessary). If it's an ASP.NET website, you'd select w3wp.exe, then hit Attach. Set your breakpoints and hopefully you're now remotely debugging the code.
AFAIK - the VMWare option lets you start up code inside of a VM but debug it from your workstation.
Visual Studio comes with a remote debugger that you can run as an exe on your server. It works best if you can run it as the same domain user as your copy of visual studio. You can then do an attach to process from the debugger on your machine to the IIS process on the server and debug as if it was running on your machine. You get more options for .Net debugging, but there's support for older platforms too.