Quote:
Originally Posted by Searinox
A series of questions actually.
I had been using SAV and NOD32 together on 32bit for over an year before I moved to 64. I had not ONCE had one BSOD. Of all AV combos I had used these two got along perfectly and I don't want to remove one without knowing for sure if it is the cause of my trouble.
Comodo would indeed be a likely suspect. I am a frequent poster on their forums and I read BSOD topics. Sadly, as the title says, I cannot make further sense of the crash dump. So I would kindly ask you, if you have found out a problem with Comodo, to provide me with details of the memory addresses and faulting DLLs/SYSs/EXEs that brought the system down so that I may report to them. Again I have been using CFP with WF and SAV and NOD32 for over an year without any incidents of any sort.
I realize these are 64bit drivers and apps and could very well have stability differrences from the 32bit ones. I will start by disabling the Windows Firewall service.
Can you trace back which kernel module rundll32.exe had upset?
|
Hi Searinox. . .
I did read several of your posts including some on COMODOs site. What I am still at a loss to understand is why one would want a personal firewall when the Windows Firewall is just as adequate for inbound threats and uses less resources. I know that WF lacks outbound "skills" but have found it can be configured for such, although not as easily as others.
My thoughts are that if something breaches your system and begins phoning home, either the inbound firewall failed or the user bypassed the inbound firewall by allowing the offending item in to begin with. So the point of having an outbound firewall becomes moot, if not THE firewall.
When I see failures, be them BSODs, app crashes or app hangs w/ 0xc0000005 exceptions (access violations), I know from processing thousands of dump files (BSOD & non) that the cause is usually a kernel mode app that has the ability within the system to to things like block NETBIOS ports. The 1st thing I look for is a 3rd party firewall.
As for ESET and SAV, I have no problems with either, although I prefer and use ESET only, but in your case why did amon.sys show up when eamon.sys took its place in more recent versions? Your version of ESET contained amon.sys w/ timestamp of May 2007 - bound to cause problems, possibly a 0xc0000005 exception itself. A bad driver - not in its day, but not meant for a Vista x64 SP1 system. Have you updated ESET NOD32 to the most recent version?
Yes, rundll32 was the process listed at the time of the crash, but as you know it is used to run other programs in a way like svchost does with system services. You can execute rundll32 at the command line. I have no way of figuring out from a mini kernel dump exactly what transpired in relation to sys, dll, exe files, device objects, driver objects, etc... as the page file would be needed to convert physical memory addresses to virtual ones. Even with a full kernel dump that would contain this information it is a tedious process, but rather near-impossible process b/c source code is not available nor are 3rd party product symbols.
I have rarely gotten to the depth of trying to figure all of this out because I take for granted a stable hardware platform and most certainly that Vista itself is not the cause of any BSOD. I have seen BSODs where Vista did turn out to be at fault - but those involved cracked copies or corrupted Vista installs. So I usually recommend the re-install of Vista w/ no introduction of 3rd party products and if failure occurs, then hardware would be #2 culprit.
Apologies that I don't have more to offer you at this time.
Regards. . .
jcgriff2
.