We are developing an (internal) web service based on asp.net 4.8, with a fairly extensive REACT SPA front end.
For debugging purposes during development, we run an IIS server on the local (development) machine, and we do something separate to run a proxy web server for debugging the .js front end SPA (not relevant to the question at hand).
When we start up a Debug session in Visual Studio (2019), VS starts with "Contacting web server to start debugging" and then locks for a time. It clearly does something to start the web server (w3wp.exe), and waits for some reply, before doing what it is told to do in the "Start Action" section of the Web tab on the project properties page.
This is problematic behaviour because it does not attach to w3wp.exe until after it finishes it's "contacting web server to start debugging" operation. This is a huge problem, as our w3wp.exe starts doing all kinds of things that we have no visibility into.
So, can anyone explain to me:
What does VS actually do to "contact the web server"?
Can this be controlled? If so, how?
Can I get the debugger to attach to w3wp.exe right away?
Why does w3wp.exe start up and load its collection of binaries, only unload them and reload them, sometime multiple times?
In short, what the actual heck is going on under the covers at startup?
This (Identity Server 3 Contacting the web server hangs when launching debug mode) question and answer seem irrelevant to my situation
I note the field Override application root URL in the Servers section of the Web tab of the project properties and had hoped this might have something to do with it, but I cannot see any relation.
Partial answers that I will either edit as I find more info, or modify if others correct me, or delete if someone answers completely. The answers to (1) and (2) above are this:
VS obtains the URL of the target web site (I will call this targetServer) from the Project URL entry in the Servers section, Web tab, of the Properties page for the web project. This actually comes from the <webProjectName>.csproj.user file in the project directory. Depending on the selection of the drop down specifying the server type to use, it comes from:
IIS server (<UseIIS>true): the <IISUrl> element
External Host (<UseCustomServer>true): the <CustomServerUrl>
IIS Express: unknown
WARNING: When opening a project with <UseIIS>true, Visual Studio has the very nasty habit of interfering in the setup of your IIS server: it insists on changing the "Physical Location" attribute of the IIS server (that is, the server or virtual app, however you have it set up) to point to the project directory of the web project. Using the "External Host" option avoids this - see https://stackoverflow.com/a/48753054/1082063. (All other discussions of this issue that I have seen incorrectly say this cannot be controlled.)
VS then issues a request to the url <targetServer>/debugAttach.aspx, and the request shows as neither a "GET" nor a "POST", but a "DEBUG", whatever that is. Not sure what VS expects back from this before doing the specified Start Action
Presumably after VS gets some reply from its DEBUG request, it will attach to the process that resulted from this request. Not sure how it knows which process to attach to - perhaps the debugAttach.aspx returns process information?
VS finally executes whatever Start Action is specified in the section of that name on the Web tab of the project Properties.
I strongly suspect that the answer to (3) above is that one cannot get VisualStudio to attach any earlier than it does because it must use the information returned from the debugAttach.aspx request to know which process to attach to. However, putting the line System.Diagnostics.Debugger.Launch(); at the start of Application_Start will allow you to attach the debugger earlier when necessary. (In practice, once you get Application_Start correct, you seldom need to debug it.) See this: https://weblog.west-wind.com/posts/2011/Dec/15/Debugging-ApplicationStart-and-Module-Initialization-with-IIS-and-Visual-Studio for a very good article on the subject.
(4) was a result of quirks in our Visual Studio setup. The initial "hack" used to get around the WARNING in answer (2) just above, was to have a web site with a dummy "virtual path" and have the IISUrl element in Visual Studio point to this virtual path. Then VS could change the Physical path of this virtual path, and we didn't really care, because our Start Action was to start a proxy server for debugging .js in any case. The issue was that this resulted in two calls to Application_start, running on two separate threads: one for the main server and one for the virtual server. Because one of these was happening before the attach happened, we never knew it was happening and it was never caught in a break point. When our application_start became long (timewise - this is not a web server for public consumption...), the two executions of application_start became a nightmare.
The issue you're seeing in IIS is that VS is not launching w3wp.exe, but rather Attaching to Process. In order for VS to attach though the EXE has to be running first, and the time between starting up and attaching (if not already running) ends up being too late to catch the ASP.NET app initialization logic in Application_Start and Module initialization.
As mentioned in my old post there are several ways you can get this to work:
Restarting the application when the debugger is already attached
(by making a change in web.config to trigger an AppDomain reload)
Adding an explicit Debugger.Break() call in Application_Start
Use IIS Express to debug startup code
Related
After moving all my solutions over to a newly installed machine (which makes me think this is a config issue), I am now having this problem with my MVC 5 web application(s).
When I build my web application (VS 2013), this of course regenerates all the web code and IIS will restart the application on next page load. However now it seems, when I go to my start/login page, the Application_Start() fires as expected, but when the page is submitted, before the HttpPost method is reached, the entire application seems to start again (Application_Start runs again). This second start seems to occur before the first Application_End() is called...but regardless of the sequence I have no idea why this is now an issue.
Checking the application shutdown reason in Application_End() I get the notorious vague (and apparently completely undocumented) "BuildManagerChange"...which MSDN gives some ridiculously vague description of.
Does anybody have idea why this would start after loading my development environment onto a new machine. Both machines are Win7 Pro running IIS7.5, and I believe the IIS config is identical to the old one (though, apparently not??). The source code/web.config/etc has not changed between machines.
The only documentation I could find on this issue was in regards to using IISExpress, however I am using the standard IIS7.5 installed with Win7 pro.
Edit: After removing all custom code from the entire startup of the site, and reverting my LoginController back to it's original simple form (no custom code), this still occurs.
Well, wasting 2 days on this was fun! But, this was resolved. Running procmon showed that hash.web was being accessed by mcshield.exe (McAfee AV). Apparently the live "on access scanner" checks the asp.net cache, and somehow IIS is aware of this and thinks it needs to rebuild the site again. For some reason McAfee does not check it after this first time so it functions normally after a second build/restart. I added a scanner exclusion to the c:\Windows\Microsoft.NET folder, and that seems to have solved the issue. –
A bit late to the party, but maybe it'll help someone. For me it was because I accidentally mapped two IIS sites to one directory. This resulted in two IIS background worker tasks and Application Application_Start() being called twice even though the second site was marked as "Stopped" in IIS.
It may be a silly question but why one would like to attach debugger to IIS instance?
These SOs
Attach Debugger to IIS instance
How do I attach the debugger to IIS instead of ASP.NET Development Server?
show you how to do it but could you let me know what are the benefits of doing this?
One time, in my entire career, we had a web app that started getting strange errors that had us baffled. We tried a dozen things to try and figure out what was wrong, but we were panicking and needed an answer immediately. So, we attached a debugger to the production instance and set up a few watch/break points. It helped us track down the errors and fix the problem.
Naturally, it hung the server during our debugging session, and made people mad, but no more mad than they already were, because of the problem we had.
It would not have been necessary if the code had been written better, with error logging and diagnostic points. I don't expect to ever do it again.
Apart from TimG's post a couple of reasons I can think of are:
To debug the application in a closer representation of its
production environment
To debug on a remote machine
Example, like #TonE #1 -- in order to test a deployed website (with web.config transformations) locally, like if you can't remote debug a live website or just need to test config transforms (since you can't run them in-place):
Open site project from C:\Dev\AwesomeWebSite\AwesomeWebSite.sln
Publish the site to a local folder C:\Webs in Release mode (or Whatever mode)
Set up a local IIS website pointing at the published project
Do stuff on the locally-deployed version (e.g. browse pages, make webservice calls, etc)
Attach VS to w3p.exe (appropriate instance) in order to debug the deployed version
You might be able to effectively do the same thing by instead pointing the Project at your IIS website per this answer.
I deployed an ASP.NET web application last night and I when I woke up this morning it was very slow and would occasionally just throw a 'Service Unavailable' error.
I checked the Event Viewer and it was filled up with these errors:
An unhandled exception occurred and the process was terminated.
Exception: System.Runtime.Serialization.SerializationException
Message: Unable to find assembly 'MonoTorrent, Version=0.80.0.0, Culture=neutral, PublicKeyToken=null'
I'm puzzled as it was working perfectly when I deployed it (MonoTorrent is required to retrieve the number of seeders/leechers for a certain torrent off the tracker - this was working fine), but it's no longer working and whenever code that uses MonoTorrent gets involved, the worker process just crashes.
MonoTorrent.dll is in the /bin/ directory.
UPDATE 6/4/10: I compiled the MonoTorrent source code in with the rest of my web application, but it still crashes whenever it uses MonoTorrent. However, it now says that it is Unable to find assembly 'OpenPeer, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null. Here, OpenPeer is the name of the web application's assembly.
This can happen in these circumstances:
The ASP.NET app creates a background thread, which throws an uncaught exception. It looks like ASP.NET catches the exception and wants to log it to the Event Log. To do this, it sends this exception from the Web app's app domain to its own app domain (the default one of the w3wp process). This needs a serialization/deserialization of the exception.
If the exception is a custom one (i.e. defined by the Web app), it cannot be deserialized in the main app domain of ASP.NET because the assembly defining the exception is typically in the Web app's bin directory, not where w3wp.exe is (c:\windows\system32\inetsrv). This causes a serialization exception and w3wp crashes.
There are possible ways to fix the issue (in a - very subjective - order of preference):
Copy the missing DLL in c:\windows\system32\inetsrv
Install the missing DLL in the GAC
Remove the cause of the exception (harder to do than to say, as we say in French)
Catch all exceptions from the background thread yourself and do the logging yourself.
Notes:
If WCF is used and the uncaught exception is FaultException, WCF swallows it and there is no crash
If the uncaught exception is in the thread of the Web request, there is a yellow screen of death, not this serialization exception
It really seems like a bug in ASP.NET
The above is actually a summary of my investigations of this issue yesterday and are only a theory. I tested fixes 1 and 4, as well as using FaultException.
Here are some things you can try..
1.) Flush ASP.Net Temp directory. Restart IIS and recycle Application pool.
2.) Make sure your web-application is running in FULL-TRUST if it really needs FULL-TRUST.
3.) Take the Assembly, try to use it in other asp.net application and run the test application on a seperate server. This might help you diagnose the problem. Also try to run the test asp.net app on the same server but in seperate application pool.
4.) Make sure the IIS website of your application is running under the user account with necessary security priviliges. Try running the application under Administratotr as user.
EDIT-1
5.) Also check if the assembly version is the same as mentioned in web.config. If there's a version mismatch then you can do AssemblyBinding Redirection in web.config.
6.) Also try registaering the Assembly in GAC and see if it loads properly.
EDIT-2
7.) Try reconfigring ASP.NET support on the server or maybe framework runtime re-setup may help. This may not be a sure-shot solution but looking at the problem condition we may want to try various solutions.
8.) Make sure you're not missing any critical update of your windows server platform.
I try to give you some ideas - what I do if I was on your position.
First of all I take a long look of the MonoTorrent.dll before some days that you make your question, and I look it again today. I found and the function that load the dll. My first opinion is that something have to do with the permissions.
I hope that you have access to the server - right ?
My first steps is that:
Ensure that your monotorrent.dll actuall have the right permissions to the bin directory, for Read, and execute by your asp.net app. Some times the copy of one dll, did not get the directory permissions buts carriage out his own permissions. To check if your dll have different permissions from the rest, just right click and see Properties | Security, then go to bin directory and do the same, and compare the Security permissions. If they are different then apply again the Directory permissions and make sure that the dll inherited by the directory.
My second step
Download the ProcessMonitor from sysinternals
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
Run ProcessMonitor and try to recreate the error, stop it and analyse to see where and why the dll gets the denied permissions to run.
With the ProcessMonitor you can even see if there is any dll that can not found !
I have check the MonoTorrent dlls and I do not found anything unusual. He have kerner32.dll calls, and use unsafe code to run, ok nothing so special about.
So if you do that 2 steps and give me some feedback, maybe I can go further. (if not solve by you and what you find)
I would advice to setup Regular maintanence probably once in a week at sunday night etc for following,
Delete all temporary files
Delete all ASP.NET IIS temporary files
Restart Server
Problem is, ASP.NET web apps cause lot of temp files to be left in the disk, because of dynamic compilation of regex, seriliazation assemblies etc, such temp stuff never gets deleted, and more and more junk starts getting collected in temp locations, ASP.NET goes slower and slower, and a point comes in where disk as well as memory defragmentation reaches very high point, things start to fail.
No body likes to restart server once a week, but I remember we had no choice, in ASP.NET 1.1 we had stable system after restarting every day, in ASP.NET 2.0 onwards, we are good to have restarting scheduled at once a week.
I have found this problem and I have do all of thing as I can, such as clear temp file, restart server, delete and add reference and I also rebuild the solution. However I can't solving this problem. Finally I move my entity class (almost of them need to serialize) to new folder that I have added to the project and then this problem solved.
This method is work for me.
Try clearing the ASP.NET temp files. It's solved some odd issues before for me.
Otherwise, Fusion-logging may shed some light.
UPDATE: #Charlie - I'm not sure what to make of those logs...it looks like the failed log is from a different AppDomain. Notice the AppBase is set to "file:///c:/windows/system32/inetsrv/" and AppName is w3wp.exe.
I'm pretty sure the Event Viewer should show Application Id: LM/W3SVC/#/ROOT if it was the default AppDomain, too. At this point, all I've got is random guesses.
I notice you're running x64...does MonoTorrent perhaps require x86?
Have you double checked that the directory is an IIS application, and is configured for the correct version of ASP.NET?
Is there some other application that uses MonoTorrent on this server? Maybe a WCF service or something? I'm not sure where the Serialization is happening....
Try hooking the AssemblyResolve event and loading it manually.
Can you repro on a development machine? If not, maybe it's a borked FX install. Uninstall and reinstall.
Does restarting, recycling or stopping/starting the AppPool fix the issue temporarily, or cause the issue to appear?
You may want to type out your screenshot text too so you'll get some Google love....
Is the server timezone different than your timezone? I've had this issue when deploying resource files, the compile time was in the future so they would fail to load.
My guess that you have plenty of open but not closed connections. I mean the connections are not returned to the pool. It looks okay, when you start the application, but after some time there are only several sockets available in the pool and it goes slow. Another thing - non-closed connection may keep DLL in memory, not allowing to release the handler. Try to debug object destruction.
I know it's simple but I had this problem once and itwas because I had a Web Application project which contains
References
Folder and I just copied my files into a
Bin
folder, in any .net web application in the Project Properties windows, a Reference Path tab is available which by default should nothing be include on it. check this option and also Build tab in Project Properties window which Output path be as the same as bin\
Can anyone help me with this error?
alt text http://abbeylegal.com/downloads/parsererror.jpg
full image here
It happens usually once a day when trying to load any one of a number of custom asp.net pages in my sharepoint web site. If I recycle my application pool the error disappears (usually for the day).
So far this is what I’ve tried to eliminate the error (which has helped reduce the number of occurrences, but not solved it)
Set the IIS_WPG, Local Service and Network Service account to Full Control permission
on the folder
%windir%\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files
Added
<machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validation="3DES" decryption="3DES"/>
to the web.config file section.
Recycle the application pool every two hours
My gut feeling is some sort of file locking issue. Have you tried running Process Monitor and having a look at the trace when this error occurs? Be warned that running it may sap some resources on your server.
To use, follow these steps. (You may also find Mark Russinovich's blog useful.)
Set the filter so that it only displays the w3wp.exe process. This will reduce noise. The simplest way is to right-click on 'w3wp.exe' in the list and select Include 'w3wp.exe'.
The monitor should have automatically started so now just wait until you receive the ASP.NET error. Make a note of the time the error occurs! It may also be reported in the SharePoint ULS log.
Stop Process Monitor from capturing events (File, Capture Events) and narrow down to the time of the error.
Look for the word 'FAIL' or 'ERROR' (you can use the program's find feature) and see if you can work out what's happening. You may need to remove the filter as the problem might have occurred with another process besides w3wp.exe.
There may also be interference with an anti-virus program as I've seen these lock files and cause problems on SharePoint before. Can you try disabling it to check if the error disappears? Alternatively, here are details of locations that need to be excluded so that SharePoint can operate correctly with a file-level virus scanner. You may need to add others, I don't believe that list is comprehensive.
I can see why the app pool recycle works, the dll's get recopied to the Temporary ASP.NET files folder.
The question here is, why are they not there anymore? It could be that the files were locked when the app pool recycled overnight, the files were not overwritten with a new version and remain in a locked state. Maybe search crawl was running when the app pool tried to recycle, visiting that page at the time?
P.S. Is your custom page build as part of a "Visual Studio Web Site" or a "Visual Studio Web Site Project"?
This may seem like a silly question, but we are having an issue debugging IIS in a shared test environment and I'm hoping that someone out there can give us an answer.
We have a Windows Server 2003 that is running IIS 6 and sharepoint 2007. We are debugging locally on the server with visual studio 2008.
When someone attaches the debugger and steps through the code, we find that all users are affected. In essence the web server stops handling all requests from all users.
Our question is whether this is a typical situation and is to be expected? Or is there some configuration that we can change that would allow the one user's session to be debugged but leave the other's unaffected.
Kev's on the right track. You need to make sure that the project you want to debug separate from the others is in its own application pool. This will isolate it to its own process and allow that process to be stopped/debugged without affecting the other applications which can remain in a different pool.
Setup
Start -> Run -> inetmgr
Right Click on Application Pools
Click New -> Application Pool
Name the new pool
Right Click on the application you want to isolate
Click Properties
Click on the Home Directory tab
In the application pool drop-down list select your new pool
Click OK
If there are any requests queued in the old process, they may take a few minutes to terminate before all requests are being diverted to the new process.
Debugging
To figure out which instance of w3wp.exe you need to attach the debugger to:
Start -> Run -> cmd
Type iisapp
You may be prompted to register CScript, if so click yes and run it again
The only gotcha you may still find is that if multiple applications are using the aspnet_state service you may run into blocking issues if you need to debug that process as well.
Links
MSDN
Developer.com
"When someone attaches the debugger
and steps through the code, we find
that all users are affected. In
essence the web server stops handling
all requests from all users."
This is normal, once you attach a debugger to a process such as inetinfo.exe or w3wp.exe and set a break point, every request/thread will be blocked until you allow the debugger to continue, until the next break-point.
I've never found a way around it. Is there some reason you can't debug on each developer's workstation?
Set up a parallel project on the server and try using that. You could use debug.mydomain.com and then just use that for testing. The only reason that I personally can think of to debug on your live servers is if there is a significant difference in the functioning of your app due to either hardware or software configuration.
Ideally you want to have a separate server/instance of your system in as similar an environment as possible so that you don't have to debug on your live machine. Also you might want to consider writing all errors to the event log or at least checking the log since asp.net usually get logged there. This way you can see where your errors are and use that to help you solve your problem in the development environment.
I believe in visual studio you can set the debugger to break only the process being debugged, and not all the processes. Depending on how your system is set up, YMMV with this.
It can't be changed AFAIK. But that's a normal practice to set up separate web-node or web-application for development/debugging purposes. If that's necessary to know exact values of some vars in certain situations you can always use debug logging.