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

Hi,

We have been testing NOD32 V3 for a while and notice that PC's with V3 installed keep are filling the event viewer with the following message.

Any ideas?

Dan

***********************************************

Event Type: Error
Event Source: EventLog
Event Category: None
Event ID: 6004
Date: 30/01/2008
Time: 10:40:53
User: N/A
Computer: WS3245
Description:
A driver packet received from the I/O subsystem was invalid. The data is the packet.

 

Yes I've seen this on my Windows SBS 2003 R2 server installed with V3.

I'm afraid i don't know what causes it, but I have had to re-install this server as I had numerous other problems (blocked access to Global Policy files, blocked user logon, blocked access to shared files) which i think are NOD32 v3 related, as seen in other threads on here.

Only installing 2.7 now

 

I haven't installed V3 on any of our servers, so no problems there.

I have only seen it on PC's were V3 has been installed, but they don't have any problems accessing the network or any resources only this Event ID: 6004 appearing in the event log.

I was hoping Eset could shed some light on the matter.

Dan

 

This is the response I got from Eset. Not really much help since I had tried Mircosoft's recomendation before asking for support and as the problem is happening since the upgrade to V3.

Dan

***************************
Private email removed and left link - Ron


http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/w2000Msgs/4356.mspx?mfr=true

 

This is a very odd response from eset. I have seen this error using nod32 3.0 and seems to happen when i access a windows share from a computer running nod32 3.0. When browsing a share the event log fills up pretty fast with a lot of 6004 events.
I posted this problem in this forum earlier without much response. When i saw this problem for the first time i searched several places to find a solution and found information about this problem from Microsoft. The document from Microsoft claim that the problem is eset in this case and NOT Windows. Below is what Microsoft says:

The driver is functioning properly but is logging incorrectly formatted packets in the event log.

User Action:
Examine the data in the event log in Event Viewer for the Unicode version of the driver's name and replace the packets or contact the supplier of the driver.

How can eset blame Microsoft because eset created a driver or some piece of software that is logging incorrectly formatted packets in the event log?

Also in case there is any doubt mcafee also had this problem with Virusscan Enterprise 8.0i, but they released patch 11 and below is taken from the release notes of their product:

3. ISSUE:
An event is captured by the Event log service with the ID of 6004. This only occurred after installing VirusScan Enterprise 8.0i, and occurred when the McAfee TDI filter driver was loaded. BZ214636

RESOLUTION:
This is resolved with the updated McAfee TDI filter driver.

Eset can blame Microsoft, but this is indeed a eset problem and if eset don't know how to fix it maybe they should ask McAfee for help since they managed to solve this problem. When eset reply it's a Microsoft problem and refer to a document that claim the problem is eset i find this really annoying. I think eset should get their act together. There been so many issues with eset since the release of 3.0 that make them look like a bunch of kids creating some software instead of a serious and professional company. I used to think nod32 2.7 where the best antivirus available, but since 3.0 my impression is that the product isn't close to the same standard as 2.7. The most annoying thing though is how they act and their response to customers that need support. I still have a license for nod32 and will stick with 2.7 until the license expire, but then i will seriously look for some other antivirus software unless there been some major changes before that time.

 

Hopefully Marcos can give us a proper response regarding this problem.

Dan

 

I wish I had found this forum two days ago. I just purchased NOD32 after a couple of days with the trial version, and while so far I really like it and it does NOT mess up my machine like Symantec did, I now have this very problem and it IS definitely due to NOD32 V3. The same computer has the same OS installed on another partition (for emergency access to files on NTFS partitions) and NOD32 is not installed there - and I have no errors at all with that install (same hardware, OS, NIC drivers, network, same everything) only on the OS install which also has NOD32.

Hopefully, ESET will get this fixed - soon - before my Event log fills up with entries I don't need to see and deletes ones I MIGHT need to see.

EDIT - this morning I uninstalled NOD32 V3 and the Event ID 6004 problem is now totally gone. Note I uninstalled because of a DIFFERENT problem which also went away after uninstalling V3.

 

I guess nobody is looking at this issue any longer, but anyway here goes:

Last night I saw that a new version was available (642) so I uninstalled version 2.7 (which has been working perfectly for me with out this issue) to try the new one. It installed fine, but the same problem is back - fills up my event log with ID 6004 errors. Furthermore, once a few errors have occured, I am no longer able to reboot the computer - it hangs at the "Saving your settings" screen for as long as you care to wait - I have to hit reset to get the computer to restart. If I attempt to restart before I have accumulated ID 6004 errors, it will restart with no issues so the restart issue seems inter-related to the ID 6004 issue.

So, once again, I can't run V3 - had to uninstall and go back to 2.7 which works fine for me.

I guess it's time for another ticket to ESET on this.

 

Hopefully you might have some better luck with Eset support! as they seem to brush this issue aside and say "its a Microsoft problem" when its clearly not!

 

I have been working on this issue with Eset technical support since December. I can assure you that the driver is NOT functioning correctly and just writing invalid error messages to the System logs on your servers. If the servers are heavily loaded enough, and if the problem is allowed to go on for long enough, the servers will become non-responsive. You'll only be able to recover from the condition by forcing them to shut down, and then booting them.

I, and others, have been posting in this forum about this problem. If the search function works for you, just search for "Event ID 6004", and you'll find our posts. You are quite correct in saying that these error messages appear when network shares are browsed.

I was just notified yesterday by Eset (They've averaged less than 1 e-mail to me per week. Horrific response times.) about the 3.0.642.0 version being available. I was hoping that someone had tried it by now because Eset was claiming that it "fixed the network browsing problem". Is that vague enough?

I should also note that tech support linked me to the home version, not the business version. I hope no one is installing the home version on servers. That won't work very well with a mirror, will it?

I'm sorry to see that someone in this thread has reported trying the new version and has noted that the Event ID 6004 issue is still there.

I guess I won't even bother testing the new version. I'm sticking with 2.70.39 for now. I just don't have time to waste on this, nor can I install a version that's going to hamstring my production servers.

This is really sad. Eset needs to straighten this out, or go out of business.

 

I've seen this problem with NOD32 3.0.566 and 3.0.621 Home editions (at least, those are the ones I've tried). Tonight I downloaded build 642. While the problem is not totally resolved, it is "different."

I'm still seeing the noted event 6004 error in the System log, but only occasionally. But MOST of the time that I try to access a network share, either browsing a folder or actually opening a file, I get the warning below instead. So now instead of the log getting filled up with 6004 errors, I'm now getting a large number of 3019 warnings instead, plus some smaller number of 6004 errors.

Is this progress?


Event Type: Warning
Event Source: MRxSmb
Event Category: None
Event ID: 3019
Date: 2/22/2008
Time: 8:45:28 PM
User: N/A
Computer: ECC5
Description:
The redirector failed to determine the connection type.

 

Hi, jgsouthard.

No, I'm afraid that is not progress. That is the combination of warning and error messages I was seeing all along on my Windows 2000 and 2003 servers running EAV 3 whenever network shares on them were browsed.

In fact, the 3019 warnings may not be necessarily related to EAV/NOD32 as I have seen them on many different types of Windows servers when browsing network shares through RDC sessions.

It was the Event ID 6004 error which cropped up only after installing EAV 3.x on my systems. I started calling and writing Eset tech support and posting information here on wilders.org a few weeks before I actually started seeing the servers slow to a crawl and lock up.

Reversion from 3.x to 2.70.39 resulted in elimination of the Event ID 6004 errors on all systems, and we haven't seen a problem since.

Thank you for your notes on this.

 

I saw the 3019 event using earlier 3.0 versions of nod32 as well so this is not new since build 642. I know that the 3019 event can be generated by other software as well since i seen this on computers not using nod32 at all, but the computer where i was testing nod32 i never seen this event until i installed nod32 3.0. After a uninstall it was gone and the same thing happned for all the 3.0 releases i tried so far. I tried all public 3.0 releases so far except the last one (642). Since i read that the 6004 event is still not solved i won't bother installing 3.0 until solved.....if ever solved.

So both the 3019 and 6004 events is an issue with nod32 3.0 and so far it seems like eset ignore them.

 

just fyi

today i installed the german version 3.0.636 on a couple of servers. after some hours all of them got slower and slower and then stopped to respond. i have nothing in the event log and tried different settings, but no success.
all of the servers are running w2003, one enterprise, the others standard. the enterprise server is a 16 core machine with 64 gigs of ram and 4 gbit nics, but this one also stopped complete.
all of the servers have more than one nic, could that be the reason?

where can i get version 2.7x ?

br

nico

 

We have seen this 6004 error preceeded with lots of mrxsmb warnings since we first installed nod32 v3 BE and I wonder if ESET are looking into this at all, sofar the feedback has been more than thin and we're now over 2 months since first install, this is probably related to the browse networking problem ?

Regards Göran

 

Hello,

this problem is not related to network browsing problem which has been fixed already.

We are of course looking at this issue. I've been informed it has been replicated in house already and further investigations is going on.

 

It's about 4 months since i posted about this problem for the first time so nice to hear someone is finally looking at this problem.

I'm not sure what you mean about "not related to network browsing" though since i had this problem since 3.0.551.0 and the problem were not solved using 3.0.621. It happen when i connect/browse a windows share. I have not tried the latest version (642) since the release notes didn't say anything about this issue being fixed, but maybe it's one of the "Other small fixes"? It would also be nice if every fix is listed in the release notes instead of the line "Other small fixes" which contains fixes that you don't find relevant to mention. For some it would be nice to know what the "Other small fixes" actually is.

 

Network browsing problem is fixed in 3.0.642:
- fixed issue with network browsing
http://www.eset.eu/support/changelog-eset-smart-security

The problem prevented users from browsing the network when using shortcut "View workgroup computers"

 

The change log posted at the Eset site is simply not descriptive enough to be of any use to those of us with problems running version 3.x of EAV on Windows servers. The Event ID 6004 error being discussed in this thread is, indeed, not related to the specific "network browsing problem" to which you refer because that is a problem the ESS firewall, not a problem with EAV, but this error most certainly is related to network browsing.

I had to roll an entire production domain back twice from EAV 3.x because access to shared folders on the Windows servers (2000 SP4 and 2003 R2 SP2) resulted in strings of these errors. As time passed, the servers became so unresponsive that I could not log on to them via RDP or at the physical console. They had to be forced down by holding the power button depressed for several seconds, rebooted, and scrubbed clean of EAV 3.x before they could resume operation.

The errors were also provoked by use of CLI commands like copy, xcopy, and robocopy in scripts. All that had to happen was for any entity to try to get access to shared folders on these servers.

I have not tried 3.0.642 yet, and I won't be trying it, until Eset gets this version properly tested and vetted for use with corporate systems. Eset's assertion that the "network browsing problem" is fixed is misleading, to say the least. There appear to be a lot of issues with network browsing, and Eset needs to be MUCH more specific in their change logs and bug fix reports.

 

I did not have ESS installed - ever - I only ever had EAV and it was installed on a Win2K Prefessional workstation and it was this machine that had the 6004 problems. They could be consistently "triggered" by browsing or copying files to and from a network file share. To a slightly lesser extent, they could also be triggered by simply browsing the WWW -or at least while I would still get 6004 errors, I just wouldn't get as many of them.

I did put in a ticket to ESET on this, submitting a Belarc profile and also a HiJackThis profile which they requested and finally heard back from them yesterday - stating that they were aware of the problem and working on it, and that the recommended solution in the short term is to uninstall V3 and roll back to V2.7. So I did this - again. I had originally replaced 621 with V2.7 because of this problem, and most recently replaced 642 with V2.7. Both times this completely eliminated the problem.

 

Hi, jimroe

Yes, I had surmised that you were using EAV only, as was I. As I was saying to mayt, there is a good deal of confusion caused by the somewhat-less-than-explicit information that Eset posts regarding bug fixes in its change logs. My attempts at communication with tech support were not very satisfying -- at least until recently when Marcos took a hand.

Alas, all they can tell me, as you have seen, is that there's a known problem and that they are working on it. I think we had already figured out for ourselves that we had to go back to the earlier version. I am just happy to see the fact that there is a serious issue finally being acknowledged, though that communication itself is vague enough to make me wonder whether or not Eset is really fully aware of how serious the implications are.

This bug is a real show stopper, and I have only heard of two Windows servers (one 2000 Advanced and one 2003 R2 Enterprise) whose admins claim not to be seeing the issue. I certainly have not been able to build a single server configuration that doesn't suffer the problem with EAV 3.x installed.

Eset, as I've said before, has an opportunity to make real inroads into the corporate community, but that opportunity is slipping by. There is a lot of really awful corporate antivirus software being peddled these days, and some of the biggest players are selling the worst of it. Eset needs to shine now. Version 2.7 does shine, but has pretty limited admin features. I would have been delighted to see version 3 simply build on the huge strengths (small footprint on the drive and in memory, low CPU usage, clean functional design) of 2.7 and just give us the improved admin features and clean up the UI (if they felt they had a need to do that). Instead, version 3.x is, so far, as much of a nightmare to me as the version 10 SAV CE and 11 SEP had been.

Believe me, when I compare someone to Symantec, it isn't a compliment.



Long time users (on personal machines) know that Eset has done a splendid job in the past. I've got my fingers crossed for them now. Because at any point where version 3 is still showing these issues and I lose support for 2.7, I'm going to be stymied as to whose software to try on my company's network. The servers are so severely hammered that there's simply no chance of using any other antivirus software I've tried. This network could be running without AV protection some day.

Have a good one.

 

Ok, I just received some of these messages yesterday evening and I suspect that it may influence network access for our clients, Note that these messages rareley occour on servers on our site mainly (almost soleley) for clients accessing the servers.

Regards

 

As servers have scanning of network drives disabled they don't suffer from the 6004 error. But as we do want NOD to scan files users open, create, etc from servers on their desktop PCs they do.

 

Ok I am jumping on the bandwagon here but I just want ESET to know how many people are being affected by 6004 and 3019.

The main point is these errors are 100% reproducable and should have been caught in testing not by users.

Disabling network scanning doesn't stop these errors for me. I think these errors dont occur on a server becuase the server does not access any network files.

We have been told this has been reproduced and is being looked at.
I suggest rather than "various bugs fixed" in the next change log that ESET document the issue in an online KB article so we can see that they have fully understood the issue and how they have fixed it so I have enough confidence to rollout to 40 odd workstations.

PS Please give us a mailing list to subscribe to so we dont have to check the web site every day.

Thanks for listening

Mike

 

Just to let you know --

If you try accessing shared folders on the server itself FROM the console or an RDC session you'll see the errors occur on the servers. I have to check my DFS daily through the administrative tools on my DCs. When I was running EAV 3.x on them this caused an absolutely 100% reproducible occurrence of the Event ID 6004 errors in the system log each time. The error does not, of course, occur when running pre version 3 NOD32 on the same servers.

The fact is that the 6004 errors are more serious when they occur on servers because they apparently are part of a process which leads to the eventual total compromise of server functionality. At least in my experience this, too, was 100% reproducible. The servers would eventually become totally unresponsive to RDP and to physical console input. The only way to recover was to perform a forced shutdown and restart them.

The Event ID 3019 warning messages -- at least the ones that occur on my domain -- are fairly common during browsing of shared folders from console sessions on servers. I've seen them in every AD domain, and that's with or without any version of NOD32 running on the servers.

I'm glad to see you also making the point I've been making -- that Eset needs to address this issue formally with precisely worded information to confirm that they truly realize the magnitude of the issue and (at the appropriate time, I hope) that it has actually been fixed. Vaguely worded change logs like the ones we've been seeing are absolutely useless -- in fact, downright counterproductive -- for those of us who are sysadmins.

If I don't see precise information about the bugs and the fixes from Eset, I won't ever be putting EAV 3.x on my production domain again. And when the license runs out next year, I'll have to find a replacement antivirus package. Or I'll do without. Yes, without. I have never had downtime on this domain from malware of any kind. I've had plenty of downtime due to issues with antivirus software from Symantec and Eset. I'd hate to have to resort to running without AV protection, but I'll do it if I'm convinced that the "cure" is worse than the disease.