Recently, I had to figure out that if SQL Server 2016 can be used for SharePoint 2013. Now, version compatibility is a must. Initially, I did assumed that since, SharePoint 2013 works pretty well with SQL Server 2012, it should work with the higher version of SQL Server as well. However, that’s not the case.
To debug a SharePoint site (or, asp.net) hosted in IIS, we need to attach the corresponding w3wp to Visual Studio. However, if you have multiple sites running in your IIS, you’ll find multiple w3wp processes [Worker Process] running in your task manager. The problem is that you can never tell to which site, a given w3wp process is associated with merely looking at the task manager.Alternatively, we can attach all the process to visual studio but it will only make it slower. To identify the actual process, we can simply run a command at the command prompt or we can directly get the info from the IIS Manager.
Navigate to the path:
For IIS 6
Run the command,
For IIS 7
Run the command,
- Go to run and type, inetmgr and press enter.
- In the IIS Manager, select the server name in the left panel.
- Then open “Worker Processes” from the main screen, under the IIS section.
- You can see that the unique Process ID has been mentioned against each app pool entry.
NOTE: Application pools by default (even in IIS 6) will only spawn a worker process (w3wp.exe) on the first request to a web-application hosted by that particular pool. The w3wp.exe instance will then remain alive for another 20 minutes (assuming default settings) and if no other requests for that application pool come in, IIS will shut the w3wp.exe down – remark that the pool is still active. The setting that controls this is the Idle Timeout in both IIS 6 and 7.