The Comodo firewall presented a popup which asked if I wanted to allow dllhost.exe to access the internet and after I blocked it the Firewall blocked 13 more attempts over the next 10 hours. Although 8 of the attempts were to contact my DNS host the other 5 attempts were to contact 3 different Microsoft entities within the ranges of the following IPs according to the reverse DNS lookups I did…
207.46.170.10- Microsoft Global Net
65.55.21.250- Microsoft Corp
64.4.31.252- Microsoft Hotmail
I’m inclined to continue blocking dllhost.exe’s access to the internet, but I am wondering if there might be some long range consequences I’m not aware of?
Well, dllhost.exe manages DLL based applications so there aren’t many reasons why it should want to access the net. However, it’s fairly safe to say that if it’s connecting to Microsoft, it’s not a big deal, but then again, why is that needed? There could be many reasons, however if everything is working fine I would recommend to just keep blocking it.
This could be one explanation though.
This program is required access the internet, in order to have a sucessful installation of Microsoft .NET Framework (my ocurrance happened during the installation of version 1.1). Only allow access if downloading from http://www.Microsoft.com or Windows Update. Windows XP SP 1 or SP 2 is required. See also: Link
Fazio93- Thanks for the reply and the Quote. I’m wondering why neither that quote nor any of the other 100’s of replys on that page or any other site that I have checked out has ever mentioned dllhost.exe communicating directly with Microsoft oline as the Comodo Firewall Pro has been reporting??? So far this communication attempt is being reported in the Firewall Log as checking in with Microsoft about every 90 minutes for sometimes as many as 4 successive attempts in a row which are now being blocked by the Comodo Firewall Pro. I would think that someone would have seen this before and mentioned it, but I haven’t come across any posts of that nature yet.
Did you check to make sure that your dllhost.exe is the legitimate one from Microsoft (located in C:\Windows\System32 and about 5-6 Kb)? A fake dllhost.exe can be caused by the Welchia Worm copying itself as dllhost.exe. If it is clean, I wouldn’t worry about it too much. Like I said, if everything is working fine, I would keep on blocking it. No harm being done. You can also create a rule in your firewall network policy to block and NOT log these outgoing requests from dllhost.exe if you would not like to see them.
Yes, the dllhost file under observation is located in the System32 file and was determined as clean when I scanned it with my A-Squared on demand scanner. As you suggested I may turn off logging after a few more days of observation, but I plan on keeping an eye on its reporting habits for a while longer as dllhost was blocked 7 more times by the Comodo Firewall Pro just during the time I was typing this.
I sorta seem to recall that when installing DotNet you can opt in to send anonymous data to Microsoft for user experience research. May be that is what is going on.
Just thinking out loud. You could try a repair or clean install of DotNet Framework and opt out?
Eric- Thanks for your input and I did install the .NET Framework 3.5 Service Pack 1 update about 6 months ago manually through the Windows Update, but there was nothing to opt on or out of that I was aware of. I didn’t notice any of these programs like dllhost.exe and now explorer.exe wanting to go to the internet to report in to MS until 3 days ago so I am not sure if that is the cause of the current problem although I did turn off Windows Update about 3 days ago and I am wondering if that might have something to do with it.
This morning I used Macrium Reflect to re-image my computer back to April 14th before all of this started to happen and I’m hoping that a fresh start may bring the end to these programs seeking to contact MS several times each day. I’ll keep you posted.
Eric- I still don’t know what the cause of dll.exe trying to access the internet was, but I re-imaged my computer using an earlier Macrium Reflect backup that I had made and I haven’t had this problem since.
So maybe Comodo is now doing the same thing. I just get exasperated with having to always click Allow. I can’t get the files to stay in the TRUSTED files
