Thoughts from the EPS Windows Server Performance Team
Useful Microsoft Blogs
We often have to work with customers to understand why a specific IE scenario fails. In some instances we may have to enable some custom logging and data collection to get to the root cause. However, understanding why we are doing what we are doing is crucial from our customers' standpoint especially in the post-mortem phase when it's time to explain why something happened. Understanding the concepts is a key component in understanding the root causes. To assist in understanding those concepts, we're going to cover a couple of key components for Internet Explorer. Today we're covering the WinINet (Windows Internet) Application Programming Interface.
The WinINet API was added to Windows in Windows NT4 and Windows 95. This API set is located in Wininet.dll and is used by WinINET-aware applications such as Internet Explorer, Media Player, and Instant Messenger. The WinINET API itself enables applications to interact with the Gopher, FTP and HTTP protocols. WinINet abstracts these protocols to provide application developers with an interface that resembles standard file IO. Something important to note here is that WinINet is not intended to be used by a server application or Windows service. This is due to the user interaction that is often required by applications that leverage WinINet - such as User Dialogs etc. When writing serviced-based applications, winHTTP.dll should be used instead. This DLL is based on the WinINET API set, but has been modified so that user response (dialogs, etc) has been removed.
So how does WinINet work? WinINet leverages the underlying sockets interface and emulator to access the network as shown in this diagram. It builds its services on top of this infrastructure. WinINet also interfaces with other OS components to provide services such as security and manipulation of the TCP/IP Stack configuration. In addition, upper layer protocol implementations such as UPnP also leverage WinINet. WinINET talks directly to Winsock when making it's request. In its most basic form Internet Explorer is a Winsock application.
When dealing with WinINet issues, there are two important DLL's to consider, wininet.dll and urlmon.dll. Let's take a look at each of these. The diagram below shows the relationship of these components:
WININET.DLL: This DLL exposes the Windows Internet API. It provides the interface between applications using WinINet and Windows Sockets. Applications that use this API check to see whether an Internet connection exists, and establish a connection if necessary. To accomplish this, WinINet leverages the Remote Access API (RASAPI). Once a connection is verified, the application can open a handle to the remote resource, request a connection for a specific protocol and open sessions on that handle for HTTP, FTP or Gopher communications. WinINet provides capabilities such as:
It is during this process that any proxy settings are verified and handled, the username is retrieved (if required) and a connection is made with the server through sockets for any FTP requests. A connection to the server is not created for HTTP requests until the request is actually sent. If necessary, WinINet communicates with Crypto components such as SCHANNEL.DLL. WinINet.Dll provides support for many things, including cookies, history, header interpretation and processing (for example web page redirection and keep-alives), authentication and encryption. WinINet.Dll leverages another DLL, URLMON.DLL for various activities dealing with URL's.
URLMON.DLL: This DLL is the URL Moniker support library for WinINet. A moniker is just a nickname that is used to make an object more familiar and recognizable. The following functions are handled by URLMON.DLL:
And that brings us to the end of this post. In upcoming posts,we will discuss WinHTTP and also look at some troubleshooting scenarios which will better explain when and how to gather the proper data to assist in root cause analysis of Internet Explorer issues. I'd like to thank Brent Goodpaster, one of our Escalation Engineers, for his review and feedback on this post. Until next time ...
- CC Hameed
PingBack from http://www.ditii.com/2007/08/21/wininet-under-the-hood/
192.168.1.1 CAN'T SEARCH ON WED
BLOCK AND CAN'T GET IN TO THE ROUTER SETTING.
This was very informative and helpful
Thank you for taking the time to explain how it all works.
A couple of weeks ago we took a look at WinINet . Today, our focus shifts to WinHTTP. The WinHTTP API
How can I get the help documents about the apis in wininet.dll. MSDN doesn't give all the infomations about the apis in it ,such as incrementurlcacheheaderdata , etc
I don't see how this article is useful. Other than naming two of the DLLs that WinINET uses, there's no meaningful technical information in this article that relates to "performance".
Does Wininet.dll 8.0.6001 create SPNs with port numbers? I know KB908209 is supposed to fix this, but and I've tried to follow http://blogs.technet.com/askds/archive/2009/06/22/internet-explorer-behaviors-with-kerberos-authentication.aspx and create the registry key mentioned, but to no avail. Is there another registry required?
It is such a shame that wininet.dll needs to be running in the system. I have Win 7 Pro.
I don't use Internet Explorer, and if I would, I would still not want extra dllhost.exe process running. And Windows Internet... C'mon what is that? Heh. Tear it apart, even the name says that it's hackable and full of holes.
Best thing, for security too, as dllhost and wininet + urlmon has holes, to separate IE stuff from these, and incorporate other features to some existing, like svchost local service? To some group that all machines have running, like BFE? Power? AudioSrv? Or make a new one. You get the picture.. Best thing would be to separate IE content from Windows Internet, and separate other features, and dump the existing method.
Win 7 has survived amazingly well from enormous virus infections, like XP didn't. But now there is new generation of viruses, few examples being Stuxnet and Flame.
I do think that MS doesn't want make a major postpone to 'Windows Next', but rather go through the code once again, as a double check, issue patches for Vista, 7 and 8 (+servers), and keep focusing on 'Windows Next'.
I don't think that MS wants to offer support for Vista till 2025 and for 7 till 2030?
Issuing the issues now is a good idea.
Sincerely, A. Rayo