about once a day the .NET Runtime Optimization Service tries to use the internet for some reason even though there are no .NET applications running. why does it keep doing this and is it okay for me to block it?
here is the packet information:
File Version : 2.0.50727.42 (RTM.050727-4200)
File Description : .NET Runtime Optimization Service (mscorsvw.exe)
File Path : F:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorsvw.exe
Process ID : 0xF30 (Heximal) 3888 (Decimal)
Connection origin : local initiated
Protocol : TCP
Local Address : 192.168.0.2
Local Port : 2344
Remote Name : crl.microsoft.com
Remote Address : 220.127.116.11
Remote Port : 80 (HTTP - World Wide Web)
Ethernet packet details:
Ethernet II (Packet Length: 76)
Type: IP (0x0800)
Header Length: 20 bytes
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Time to live: 64
Protocol: 0x6 (TCP - Transmission Control Protocol)
Header checksum: 0x9a9a (Correct)
Transmission Control Protocol (TCP)
Source port: 2344
Destination port: 80
Sequence number: 284935589
Acknowledgment number: 0
Header length: 28
0... .... = Congestion Window Reduce (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...0 .... = Acknowledgment: Not set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..1. = Syn: Set
.... ...0 = Fin: Not set
Checksum: 0xd4ab (Correct)
Data (0 Bytes)
Binary dump of the packet:
We are also very annoyed by contact attempts to this CRL site and desperately are looking for a way to get rid of it !!!
Currently we are evaluating the Microsoft Workflow Foundation by writing little test applications/workflows (very simple ones).
Everytime we want to start a workflow it takes about 20 sec before anything happens. This is very annoying!!!
Using a network sniffer I figured out that the test application tries to connect to 18.104.22.168:80. Since we live in our company's intranet (firewall protected) this connection attempt fails and times out after about 7 sec. The connection attempt is then retried twice with the same result. So we end up with a delay of about 20 sec !!!
I wouldn't care if this happened once per week or even once per day, but when I do software tests and debugging this delay is really a hassle.
Can anybody help ?
Hopefully you figured this out by now. However, in case you did not, you can try the following (depending on your network configuration).
If the offending IP address does not change, I suspect that mscorsvw.exe is trying to reach crl.microsoft.com which resolves to that IP address. Then, add this line to the end of your HOSTS file on the machine from which the attempt is being made (e.g. your desktop if the IP connection originates from there):
127.0.0.1 is your local machine. You can test this out by opening a command prompt and typing "telnet crl.microsoft.com 80" (without the quotes). Your computer should reject the connection without the 7 second pause. You may also need to run a dummy process that simply rejects all attempts to connect to port 80, but I highly doubt this is necessary.
This assumes that you do not have control over the company Intranet, and you cannot convince someone to reroute connections to that IP address for you at the firewall level. If you can get the people that run the firewall to reject connections to that IP (and crl.microsoft.com), then that is the better way to go. You wll solve the problem for everyone else at the same time.
When preventing this connection from a home PC ..what method do you think is best...usually I would just stop the offending app from ever connecting to the net?
1)Stop 'mscorsvw.exe' from connecting to the internet permenently
2)Add a firewall rule to stop my PC from connecting to 22.214.171.124
3)Add 'crl.microsoft.com' to the host file
However, this still results in a delay if an external firewall is involved with OP
To quote from another forum:
"You can stop this appearing by changing your IE settings
select TOOLS/INTERNET OPTIONS
- select ADVANCED from the new window
- scroll down to SECURITY
- uncheck "check for publishers certificate revocation""
It seems unnecessary from the user's point of view anyway.
- Proposed as answer by YesK Wednesday, July 15, 2009 4:42 AM