Event ID:6004 - A driver packet received from the I/O subsystem was invalid.

OMG I thought I was going crazy trying to figure out what was causing my system to BSOD and give me the 6004 event. I have had this issue for months and had no clue what was causing it until I ran onto this thread.

Add me to the list of unhappy people with this error I just tried updating to 3.650 and did a test went to a networked drive and it gives me a 6004 if I go to 2 different network drives it gives me 2 6004 I uninstalled 3.650 and installed 2.739 and no more 6004

I am using win xp pro with a p5b-vm asus motherboard 3.4ghz pd processor and 2.7 gigs of ram

 

I been following this thread waiting for a fix and find it amazing it's not solved yet. Eset ignored this problem for a long time and now they spent pretty long without a solution. I'm still using 2.7 and wouldn't be surprised if my license expire before nod32 3.0 is ok to use and my license expire in 2009.

 

On the bright side since 3.0.650 I havent seen 6004 on any of our client systems, I haven't been checking alot of log files yet but sofar looks promising.

Well I don't think I've seen a 6004 on any of our servers but then again we only use administative rdp sessions on it and never or very rareley access file server shares.

For client issues we've had the 5 to 30 minutes log off saving profile to server, frequent 6004 and even more 3019's.

Also had some vague issues with vpn clients that I cannot directly point the finger to EAV so I don't at this time.

Regards Göran

 

can anyone else confirm that 3.0.650 fixes these event log errors.
I asked eset in uk if it did as it wasn't addressed in the change log (usual lack of info).
They said it was not fixed.

Before I install this to all my client machines I would like to know if anyone else has seen the event log errors disappear since 3.0.650

Thanks

Mike

 

Hi, Mike.

I'd say that the symptom (the error message in the System log) has been cured, but the patient is still very ill. In other words, I no longer see the 6004 error message on the test server or the two private client systems I installed 3.0.650.0 on, but, in all other respects, they are still very troubled machines. My strong advice is to avoid installing EAV 3.x on any critical system -- period. Stick with NOD32 2.7. At the very least you should test thoroughly on some non-critical systems that are configured similarly to your critical systems before deploying.

 

I too would recommend this!, we only have V3.x on a select few non-critical servers and about 60ish PC's. The rest of our Servers and PC's are using V2.7.

Once these issues have been fixed then I will look at a wider roll-out.

Dan

 

I may have some very good news at some point today. It could be that test files provided by the ESET developers through technical support contain a preliminary version of the solution to this problem. If so, it would be a flaw in my testing methodology which hid that fact from me.

Within a few hours I'm going to perform a careful test with a system which has been very badly affected by this problem. I hope to report a successful result soon. If anyone is on the verge of making a decision one way or another about which version of NOD32 to deploy you might hold off making that decision just a little longer. I'm hoping that ESET may have nailed the problem down.

 

That would be wonderful CrookedBloke, I'm holding my breath with anticipation... I have been un-able to continue my testing due to holiday & Firewall issues... I have installed 3.0.650 on my laptop, it has slowed down severely since then though, so I haven't been able to put it near any of my servers...

Good luck with your testing...

 

Preliminary results of testing -- after following directions supplied by ESET technical support and using three files supplied by them to replace components of 3.0.650.0, my test server has suddenly become absolutely stable and perfectly responsive. I have only been testing it for a couple of hours, but my problems on this server (and all of my others) have been absolutely reproducible within a few minutes each time I have tried. I am very hopeful that ESET have the solution now.

I am awaiting permission from ESET to post what little I know. Suffice it to say that, over the past few days, I at first thought they had fixed the problem, then decided that they hadn't, and have now found out why my test server suffered a "relapse". That apparent recurrence of the problem was due to my testing methodology, and it most certainly does appear that some incompatibility with UPHCLEAN was involved.

I note that some folks here have stated that they have seen performance problems / unresponsiveness on systems on which uphclean is not installed. I have no idea what these findings portend for them. I do know that much of the uphclean functionality is a part of the user profile service in Vista, so, if they were talking about Vista systems, I suppose that included functionality might be involved in their experience.

Let's keep our fingers crossed, people. ESET has, for years, been the only antivirus software I wanted to use on any Windows system. I would really like to be rolling version 3 of EAV out on my network in the next couple of weeks.

 

That's WONDERFUL news, thank you for replying CrookedBloke... I look forward to being able to roll out v3 (again) on my servers in the very near future... You have been the driving force in helping ESET find this fix, so thank you very much for all your hard work/testing...

 

Well, actually, I haven't done much of anything except test a little and whine a lot. I was inclined to disbelieve that the primary issue I was seeing was caused by an incompatibility between ekern.exe and the uphclean service. And I kept thinking that, if there was something wrong between ekern.exe and uphclean, that this meant that ekern.exe itself must be seriously flawed in the way it dealt with the user profile hive.

Fortunately, Marcos and the ESET developers were smart enough to perservere in their efforts to find the problem and to get me to test their solution.

My test server's "relapse" was, apparently, caused by my having excluded ekern.exe from the uphclean service's purview and THEN replacing the 3.0.650.0 version of ekern.exe with the test version of ekern.exe. Whether uphclean calculates an MD5SUM or whether it uses some other method of keeping track of these things, it seems that it "knew" that the ekern.exe it was seeing was NOT the one that I had told it to exlcude. Thus, I was seeing server failures again when I retested.

I have written to Robin Caron, the MS engineer who authored uphclean, to see if I can learn anything more about this -- and to learn whether or not there might be any untoward ramifications to using this process exclusion workaround.

In the meantime, I am going to test a new EAV installer that Marcos made available to me. I plan to beat on this test server overnight and post the results here tomorrow.

Marcos made it very clear to me that this new installer (and the contents thereof) have not been tested thoroughly enough for it to be released. He also said that he would make it available to those who PM him for it -- but you should certainly not be installing it on a production server. If some of you want to contact him, make sure you're straight about that. I'm sure Marcos doesn't want anyone installing unofficial software in a production environment.

I have to admire ESET for wanting to proceed carefully on this matter. I was wondering publicly earlier on this forum just how ESET had managed to release such an obviously flawed product. I feel kind of sorry for having voiced those feelings now because I can see that they may very well have been blind-sided by this entire issue.

Think about it. From what I have seen, they could have tested the living daylights out of this software on Windows servers without ever seeing a problem. How? Because they wouldn't have been running UPHCLEAN on their test systems. Their software has never required the use of this tool, which is designed to make misbehaving processes relinquish their handles on the user profile hive at log off time.

But those of us who have been running stuff like SAV CE have needed UPHCLEAN on our systems to prevent borked roaming profiles, 30 minute log off processes, and the myriad other problems caused by crudware like the Symantec antivirus which keeps on trying to scan the danged user hive when it's supposed to be releasing it.

There are a lot of people who use UPHCLEAN, but there are a lot more who have never heard of it. ESET appears to have been victimized by circumstances that are more than a little peculiar. Apparently it is possible to write an antivirus kernel that DOES properly release the user profile but which still runs afoul, somehow, of uphclean.

This does not mean that ESET is to blame -- or, for that matter that MS is to blame. There is, after all, no such thing as a "finished" product running on any actively developed OS, by definition. In fact, MS are doing beta testing of a version 2 of UPHCLEAN right now. The one I am running on my servers is the last official release -- version 1.6d.

Let's hope this pans out. I was about ready to start tearing my hair out. That would have been a lot of work. I'm an old hippie, and I look the part.

Right now I want to be a cheerleader for ESET. There are a LOT of people running really bad antivirus software out there. On most personal systems and some corporate systems the bad antivirus software may not cause much more than some inconvenience. On my personal systems bad AV software is a serious inconvenience. On my corporate systems it is an absolute disaster. SAV CE was causing spontaneous rebooting of our production servers, which is why I replaced it with NOD32.

Many, many people are looking for an improvement over the dreck that most AV vendors are selling. Now would be a really nice time for ESET to present the Windows community with antivirus software which provides great protection and admin features and which can be run on heavily hammered systems without causing performance problems. As far as I can see, ESET is about the only game in town for someone who needs that type of antivirus software. (And don't we all.)

My fingers are crossed.

 

I totally agree with you CrookedBloke, this anti-virus software is a god send, compared to the several we have tested/used this is the one which we have found to be the 'best' in all areas, but mainly in the performance area, I have and still do recommend Nod32 to corporate and personal friends, usually at the time they are moaning about their current offering (usually it must be said, Norton). I had been trying to ignore the issues we were having recently, so I didn't have to consider looking at another AV solution, we are currently in the throws of changing our backup/BMR solution (funnily enough away from Symantec) and could do without another major peice of software being replaced...

I am literally over the moon that there appears to be a fix on the way, I'll PM Marcos and trial this version on my test server, which whilst not completely hanging up, had become 'lagged' some what, this server dowsn't have the UPHCLEAN service installed, so will be a good test for those of us without that service running.

I look forward to reading your findings here in the morning(ish), good luck with the testing...

 

Yes, I forgot to mention the one small cloud on the horizon -- the matter of what causes issues with servers not running UPHCLEAN. I will watch that part of the whole thing with interest.

All I can tell you about my particular test server right now is that it functioned perfectly all day with the experimental files and the ekern.exe exclusion in uphclean's parameters. I did install the new version via the new installer provided by Marcos, but I did not have a chance to test it other than very briefly before having to leave for a meeting.

I plan to hit it hard tomorrow, though. I'm looking forward to seeing what you come up with.

 

My test server has been running the new test version of EAV (3.0.653.0) for over 24 hours with absolutely no sign of trouble.

This system runs WS2003 SP2 (not R2, however) with the UPHCLEAN service installed, and it has been extremely easy (until this version of EAV) to cause it to fail. Now it refuses to fail. Nice change.

The only proviso is that ekern.exe has to be put in the exclusions list for uphclean, requiring a registry edit at this time.

Here's hoping that ESET continues to make progress. I also hope to hear soon whether or not systems NOT running UPHCLEAN are behaving themselves with this version of EAV.

 

I have just installed the test version on one of our servers without the uphclean service installed.
This server failed within some hours with version 3.0.642.0 running.

I will report the results tomorrow

 

3.0.653 has been installed on a my test server & my live laptop (mainly because this machine had 3.0.650 installed, and had been noticeably slow) for a couple of hours now, I have transfered a fairly severe amount of data between the two machines and... wow, it's just like having 2.7 installed, the performance is back up to what it had been, and the 6004 errors have gone, completely...

Well done ESET...

Next question, when will it go live?

 

I have PM Marcos to get a copy of 3.0.653 to test here, unless someone could provide it for me.

I have a lot of problematic PC's here and would like to find out if/how it helps.

Cheers,

Dan

 

Be sure to get the file directly from Marcos. It's an extremely bad idea to try to get the new version from anywhere else. Marcos has asked that those of us who are communicating with him NOT give out the direct download link -- for obvious reasons. He wants to be aware of each situation / user who has it so that he can gather data and follow up in a meaningful manner. He will get back to you. I'm sure he's really busy, so please try to be patient.

Please keep us posted on how things are going for you.

 

So, good news from my side.

Our server with the installed test version worked totally normal all the day.
There were about 1000 files open simultaneously at peek times without any noticable delay.
Eicar was correct detected when coming trough network shares.

This is a file server without uph service installed.

It took a long time to solve the problems, but now I can say Well done!

But I am curious, what was the problem

STI

 

STI

Your guess would be as good as mine. Marcos has stated that the problem involved a conflict between EAV v3 and UPHCLEAN. (I hope I'm not putting words in his mouth. But I think that was the gist of his statements on the matter.)

Now all of my servers were running UPHCLEAN, a long-standing tradition of mine. That made the possibility of an EAV-UPHCLEAN conflict seem like a reasonable possibility to me. It also made me a little uneasy. In all of my past experience I had only ever seen UPHCLEAN have to do its thing (closing handles on the user profile hive, or rather moving them to the default user profile hive) at log off time when it was dealing with software that was misbehaving -- usually "pseudo-drivers" such as those used by various antivirus and software firewall vendors.

I was thinking that, if EAV was running afoul of UPHCLEAN in some way, that meant there was something uncouth about the way EAV was dealing with the user profile hive. I have been in communication with Robin Caron, the person who wrote UPHCLEAN, and Robin's opinion is that it's not necessarily a bad thing to have to exclude ekern.exe from oversight by UPHCLEAN. As long as there are not Userenv warnings or errors when logging off, there's no reason to suppose that ekern.exe is doing anything wrong.

However, reports of people like you who were seeing problems on systems not running UPHCLEAN were very worrying to me. I was afrait that ESET were focusing on UPHCLEAN just because my memory dumps were showing an issue between the two, and that there might be some more sinister underlying cause of the symptoms we were reporting to ESET.

Now that you are reporting that a UPHCLEAN-free system has lost its warts when running 3.0.653.0 I'm stumped trying to come up with a simple explanation that explains the fact that both you and I had problems, and that both of us seem to have had those problems solved by the new version of EAV.

Obviously there's no registry edit for you to perform. With my system, I have to add ekern.exe to an exclusion list in the parameters for UPHCLEAN in the registry. Both of us are seeing improved server behavior.

I understand that some features of UPHCLEAN were incorporated in Vista's User Profile Service. That may or may not explain why some Vista machines not running UPHCLEAN (not compatible anyway, I think) are affected. I don't believe there is a corresponding inclusion of UPHCLEAN features in WS2003, and I know that no such inclusion exists in WS2000, so it's kind of hard to see why those systems exhibit problem behavior with EAV 3.x (before this test version). It's also hard to see how other such systems are NOT affected.

Weird. But that's the sort of thing you can see when an OS allows software and drivers from third parties to run in kernel mode. It has been a issue for all of the NT-based operating systems, and that's why MS is slowly (but surely, I hope) moving toward putting all third party stuff where it belongs -- in user land. That may mean some losses in performance of that "stuff". I don't give a darn. I'll take stability over speed any day, especially on servers. These aren't gaming rigs, after all.

I could also be all wet in my analysis. But I've written a lot of software before, and I was pretty good at it, once-upon-a-time. My stuff was all machine language, and it was written for totally different hardware platforms (Zilog and 6502 among them) than the platforms that run Windows. But that experience taught me that allowing two separately-developed pieces of software direct control of kernel processes and hardware was an undertaking fraught with peril. The ramifications have NOT become simpler.

 

Marcos said earlier in this thread

"There is a special AMON driver available for testing which has one of the new scanning features in v3 disabled. This feature was not supported in v2. If someone experiencing a server lockup is willing to test it, please PM."

So my question is, what scanning feature(s) have been disabled to allow this new driver to work?

 

I tested that module, and it had no effect on eliminating the problems my test server was having. In the evolution of this issue, that was one of the earlier efforts. I think that ESET developers have gone well beyond that stage now.

I hope we will get some details if/when the next release comes out. The change logs have not been terribly informative to date.

 

Update:

I have been running EAV 3.0.653.0 on my previously failure-prone test server for almost 72 hours now with absolutely no sign of a system problem -- regardless of how hard I beat on the server.

 

Ditto, my server & laptop are running smoothly again, I'm hoping we'll get the official release soon, so I can roll all of my servers back up to v3 & get my workstations off of 3.0.642. I use my laptop to manage my forest, I am browing UNC shares, DFS shares, other w/s & servers all day, every day, I could almost say, it's like running with no AV software installed

 

Has anyone tried this on Small Business Server 2003 Premium? I downgraded to 2.7 six weeks ago after getting system lockups with 3.0. As best I can recall, I'm not running UPHCLEAN--it's not in Add/Remove Programs, and there is no file name containing "UPHCLEAN" on the system drive.

It's possible that my lockups were due to insufficient exclusions or other configuration changes (I did go six days without a lockup at one point), but after reading posts here, I felt that 3.0 was too unstable to leave on the machine, so I downgraded.

Mark