Meet some terrible problem on wininet, from call stack trace it seemed the exception is inside wininet.dll.
from: http://support.microsoft.com/kb/238425
Warning: Microsoft does not support using WinInet APIs within the context of a System Service.
WinInet APIs report access violations when used from the service over the SSL with Internet Explorer 5.0 installed.
In order to understand the limitations unique to using WinInet in a server environment, it is necessary to understand WinInet’s history. WinInet was developed for use by Internet Explorer. In fact, to use later versions of WinInet, you must load a minimal installation of Internet Explorer (see the References section in this article). WinInet also exposes APIs for use by other client applications that wish to access resources on the Internet (or intranet). It is important to recognize the environment in which WinInet was developed and tested in order to understand the appropriate use for the DLL. WinInet was developed for use in a client environment. Although it is still acting as a client when it is running in an ISAPI DLL, it is running in a server environment in this case.
Client Environment: A Person Running the Internet Explorer
•
Relatively low number of requests
•
Requests made relatively consecutively
•
Host application lifetime is short (length of browser session
Server Environment: a Web server (such as, www.microsoft.com)
•
High number of requests per second
•
Multiple threads making requests concurrently
•
Must run for weeks or months
The prefered solution is to use WinHttp, which is designed to run in a service environment, and because it is a server-side HTTP stack, it is not bound to the 2 connection limit that is imposed by RFC 2616 that client-side HTTP stacks. This API set is very similar in usage to WinInet so those familar to WinInet will find it quite easy to adapt to.
From: http://groups.google.com/group/microsoft.public.inetsdk.programming.wininet/browse_thread/thread/8cf882060ad412a1/bde28a4732cf368b?q=wininet+thread-safe&_done=%2Fgroups%3Fq%3Dwininet+thread-safe%26hl%3Den%26lr%3D%26sa%3DN%26tab%3Dwg%26&_doneTitle=Back+to+Search&&d#bde28a4732cf368b
If you Google the newsgroups on this subject, you will get differing
opinions as to how thread safe WinInet is. The answer really is “it
depends.” Internally, WinInet does try to be thread safe, but you have to
be careful not to put too much stress on the API.
(You don’t mention what type of operations you want to use WinInet for–FTP,
HTTP, etc.–so I’ll assume HTTP.)
Keep in mind that WinInet was designed only for single-user desktop client
applications. Do not use WinInet in any kind of multi-user or server-based
application, or NT service. For those kind of applications, you should use
either the .NET Framework or the WinHTTP API instead.
Within a single-user application or component, it is OK to send HTTP
requests concurrently across multiple threads with WinInet. You do not need
to serialize access to the InternetOpen and InternetConnect handles when
creating new HTTP request handles. WinInet handles do not have any thread
affinity, so you can access the same handle from different threads. However,
once an HTTP request is in-progress, you should be careful with
multithreaded access to the HTTP request handle.
During the HTTP request, it is a good idea to serialize access to the
WinInet request handle. In particular, you should avoid calling
InternetCloseHandle from another thread to abort an HTTP request that is
in-progress. To abort an HTTP request, close the request handle during a
callback (meaning you’ll need to set a callback function on the request
handle via InternetSetStatusCallback).
If your application is going to send a lot of concurrent HTTP requests
simultaneously across multiple threads, then you should consider turning off
the WinInet cache (by specifying the INTERNET_FLAG_RELOAD and
INTERNET_FLAG_NO_CACHE_WRITE flags in the call to HttpOpenRequest).
Also note that by default, WinInet will limit the number of simultaneous
connections to a given server (or proxy) to 2 simultaneous connections, per
the HTTP/1.1 specification. So if you try to send more than two requests to
the same server, WinInet will let two of the requests go through and block
the others. (This limit can be overridden using the
INTERNET_OPTION_MAX_CONNS_PER_SERVER and _MAX_CONNS_PER_1_0_SERVER options).
If you do experience instability using WinInet in multithreaded scenarios,
then switch to WinHTTP. WinHTTP also does not have the default
2-simultaneous connection limit.
–
Updated (Nov. 18, 2007): Finally we didn’t find any real threadsafe problem in Wininet, and from Wininet’s implementation code, it obviously intend to make it threadsafe enough.
The threadsafe problem we met before should caused by some other issue.
About