Where is this 'http.sys' actually located in Windows?
I can't find it in any Windows folder.
Where is this 'http.sys' file?
Where do I need to look?
I tried to search 'http.sys' on Google, but I could not find the folder.
It's located at system32\drivers\http.sys.
Windows\system32\drivers\http.sys
its available only with XP SP2 and later.
it's locate under C:\Windows\System32\drivers by name http but it's actually http.sys is kernel level layer of IIS, every request comes from client is first to http.sys and then it make a queue of every request based on application pool register number.
Related
I used to use win2003 as my server,my web applicaion file has some files like \image\forum\1.jpg.
now, i plan to use CENTOS as my server. i notice that the route in linux is /image/forum/1.jpg.
question1: is the win route format is different with linux as i recognized?
question2: how to revise the route format before move to CENTOS? any advice is welcome.
I build my code on a windows 2k3 machine and then roll out live to centos servers. It's always worked either way without changing a thing :-) It's never caused me an issue.
You should have no need to change your code
I'm trying to set up an application from a third party, which requires a supporting website hosted in my local IIS. I've created a website exactly as explained in their install guide, but am having some problems, and would like to see what the IIS log has to say. Embarrassingly enough, the problem is I can't find the log files!
So my question is: Where does IIS7 store logs by default?
I think the default place for access logs is
%SystemDrive%\inetpub\logs\LogFiles
Otherwise, check under IIS Manager, select the computer on the left pane, and in the middle pane, go under "Logging" in the IIS area. There you will se the default location for all sites (this is however overridable on all sites)
You could also look into
%SystemDrive%\Windows\System32\LogFiles\HTTPERR
Which will contain similar log files that only represents errors.
I believe this is an easier way of knowing where your IIS logs are, rather than just assuming a default location:
Go to your IIS site, e.g. Default, click on it, and you should see "Logging" to the right if logging is enabled:
Open it and you should see the folder right there:
You are welcome!
I'm adding this answer because after researching the web, I ended up at this answer but still didn't know which subfolder of the IIS logs folder to look in.
If your server has multiple websites, you will need to know the IIS ID for the site. An easy way to get this in IIS is to simply click on the Sites folder in the left panel. The ID for each site is shown in the right panel.
Once you know the ID, let's call it n, the corresponding logs are in the W3SVCn subfolder of the IIS logs folder. So, if your website ID is 4, say, and the IIS logs are in the default location, then the logs are in this folder:
%SystemDrive%\inetpub\logs\LogFiles\W3SVC4
Acknowlegements:
Answer by #jishi tells where the logs are by default.
Answer by #Rafid explains how to find actual location (maybe not default).
Answer by #Bergius gives a programmatic way to find the log folder location for a specific website, taking ID into account, without using IIS.
The 100% correct answer for the default location of the log files is...
%SystemDrive%\inetpub\logs\LogFiles
Yes you can enter this into the explorer address bar it'll work.
To be 100% sure, you need to look at the logging for the web site in IIS.
https://learn.microsoft.com/en-us/iis/get-started/whats-new-in-iis-85/enhanced-logging-for-iis85
i.e.
Open IIS Manager.
Select the site or server in the Connections pane,
Double-click Logging.
The location of log files for the site can be found within the Directory field
EDIT: As pointed out by Andy in the comments below you need to ensure when installing IIS that you elected to enable HTTP logging, otherwise HTTP logging won't be available.
A much easier way to do this is using PowerShell, like so:
Get-Website yoursite | % { Join-Path ($_.logFile.Directory -replace '%SystemDrive%', $env:SystemDrive) "W3SVC$($_.id)" }
or simply
Get-Website yoursite | % { $_.logFile.Directory, $_.id }
if you just need the info for yourself and don't mind parsing the result in your brain :).
For bonus points, append | ii to the first command to open in Explorer, or | gci to list the contents of the folder.
Try the Windows event log, there can be some useful information
Enabling Tracing may be a better alternative to the Windows Event Log. This gave me the information I needed to fix my own WebService.
I think the Default place for IIS logging is: c:\inetpub\wwwroot\log\w3svc
I have found the IIS Log files at the following location.
C:\inetpub\logs\LogFiles\
which help to fix my issue.
C:\inetpub\logs\LogFiles
Check the identity of the site going to sites and advanced settings
The simplest answer is to query like this:
(Get-Website * | % { $_.logFile.Directory});ls $GetIISLogs\W3SVC1\*
If you have more than one site you will get more than one answer, so you need to query with a 'foreach' to get the website name with the directory...
Apparently the management piece of IIS - the IIS WMI provider - is installable separately from the IIS runtime.
I'd like to produce an installer for an add-on to IIS, and I know how to check for the existence of the IIS runtime in the WIX project. But, the installer needs to do various management things, WMI things, and for that it needs not only IIS, but the WMI Provider for IIS. Which as I said, may or may not be present.
In a WIX project, How do I check for the existence of the IIS WMI Provider, and how do I present a reasonable dialog to the user if the IIS WMI Provider is not present?
The installer already has a few MSI Custom Actions implemented in Javascript, and I can use
var iis = GetObject("winmgmts:root\WebAdministration");
...to check for the existence of the WMI Provider. It will fail (throw) if no WMI Provider is there. I suppose I could use this to set a Property, and then check that Property in a Condition early on in the Product.wxs file.
is this going to work? any other suggestions?
I suppose the better way for this is still to browse the registry for appropriate setting. Another question is it's not always easy to find the right one. :)
For instance, my installer needs IIS6 compatibility to be enabled (for IIS 7 machines), in particular, IIS 6 WMI compatibility. This setting is located under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InetStp\Components, in a value called WMICompatibility. So, everything I should do is to author a RegistrySearch element to search for this value and check if it's 1.
In order to find the correct setting, I would search for the key all IIS parameters reside under (it might differ for each version of IIS, I'm not certain here), enable IIS WMI provider you need and see what was changed in registry. I suspect registry monitor software can help here a lot.
Yes, testing instantiation of the object via the moniker is going to work. It's a reasonable strategy, better than spelunking around in the registry. It delivers the right result, all the time. Just catch the exception that occurs if the WMI provider is not available.
For some magical reason ii6 started to cache pages on the server. Even if I remove the page, it is still displayed. I tried to follow couple suggestions but no luck.
That's what I did so far:
Deleted \WINDOWS\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files
Unchecked 'cache ISAPI extensions' in the IIS configuration.
Added 'Cache-Control no-cache' to HTTP headers in properties.
Tried to create the page that clear the cache http://www.dotnet247.com/247reference/msgs/13/67641.aspx
Update: also tried to disable asp cache
IIS ASP Caching
But the files in v2.0.50727\Temporary ASP.NET Files are still created
If anybody has other suggestions, please share.
Thanks.
Please give the delete permission for IIS user on below folder. these files will be deleted automatically by IIS
For 64 bit OS folder path:
\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files
My classic ASP pages WOULD NOT refresh from any browser. Finally, stopping and starting the IIS service (IIS6) fixed the problem.
You, too, can go bonkers, just like me. Simply have IIS start giving out stale pages! A bargain at half the price!
Did you try restarting the IIS server to see if that stops it from displaying? If it doesn't, then it might not be a caching issue.
I believe restarting the server is supposed to clear the cache.
Maybe the problem isn't the IIS, but a web proxy between your browser and your web server caching the page?
Or a wrong DNS settings pointing to another server which holds a copy of that web/page? You could also look on the same IIS if there is another web configured and host headers got mixed up, making you test on the wrong web.
I might just say the obvious here but have you tried recycling the application pool?
Thanks for replies guys.
I figured out that it wasn't the caching issue. I didn't cleared out Bin folder and the compiled version of the page with extension .compiled was seating there all the time. I don't what changed this time, but I followed the same process like 100 times before and copied files on top without clearing Bin.
I should be more accurate with such things.
I'm trying to re-install a DLL in the GAC, everything seems to work fine but the web application accessing it still seems to be using the old one.
The old DLL is the same version as the new one with only a minor edit, it will be used by 50 different sites so changing the version then changing the reference in the web.config is not a good solution.
Restarting the IIS server or the worker process isn't an option as there are already 50 sites running that must continue to do so.
does anyone know what i'm doing wrong or what i can do to remedy this situation?
AFAIK, you need to restart IIS for it to get a fresh reference to the updated DLL. Your best bet is to perform the reset at a low traffic time. If you are running multiple servers with load balancing, you can prevent new connections from hitting one server until all connections have been closed. Afterwards, update the DLL, restart IIS, and bring the server back into the connection pool. Repeat for each server with no visible downtime to the end users.
Since you don't make a reference to application pools, I'm going to assume you are on the old version of IIS. In that case, what you'll need to do is to "touch" all the DLLs in each site that references the DLL.
The problem is that the code is already loaded and you need to find a non-intrusive way to re-load the application. Recycling app-pools is an effective way to do this. If you are on the old IIS that doesn't have app-pools, then updating the last-modified in the /bin/ folders or web.config files will reload the application without affecting the other sites.
So a script of some kind to do the above is in order. All it needs to do is update the lastmodified on the DLLs in every /bin application directory.