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

AFAIK the 6004 problem is solved with 3.0.650 and above.

Regards Göran

 

Do you know this for a fact? According to this thread it's NOT fixed in 3.0.650 and also according to a post from Marcos in this thread the release where this is fixed is not yet released to the public unless i'm wrong. If you don't see this problem anymore doesn't necessarily mean that it's fixed.

 

In point of fact, from 3.0.650.0 onward the Event ID 6004 errors no longer appeared when browsing server shares.

However, the associated behaviors (loss of server responsiveness to logon requests, loss of remote sessions, and even total lockups) were likely to continue.

Think of it as a rattlesnake without the rattle. You don't get scared by that terrible rattling sound -- but you still get bitten!



On the other hand, Marcos provided me with the opportunity to test a version 3.0.653.0 which I am unable to cause to fail in any respect on my test server. And this test server could be caused to fail within minutes on version 3.0.650.0.

The proviso with the test version that I tried is that a registry edit had to be performed to exclude ekern.exe from oversight by UPHCLEAN. Without this registry edit, using the 3.0.653.0 version will still result in loss of RDP sessions and other weird behaviors.

For those who aren't familiar with it, UPHCLEAN is a Microsoft-provided service which monitors systems for processes which do not "properly" release handles on the user profile hive at logoff / shutdown time. It is not installed by default on any Windows OS. Some of us have just learned to install it on our systems because there are a lot of badly behaved drivers and software packages that transgress in this area, and UPHCLEAN is a nice preventive measure.

It is interesting to note that some people who are NOT running UPHCLEAN have reported similar server responsiveness issues to those I saw on my servers. I have no idea whether or not 3.0.653.0 solves such problems on their servers. Obviously, there is no registry edit to help them. If I'm not mistaken, though, one or more of these peopole not running UPHCLEAN have reported here that 3.0.653.0 has solved their issues on their systems, too.

As I said before, I have corresponded with the person who wrote UPHCLEAN. Robin said that the fact that ekern.exe needs to be excluded from oversight by UPHCLEAN is not a sign that there is really anything wrong with ekern.exe.

This looks like a really esoteric problem, and the ESET developers may need some time to get it sorted. My guess is that they would prefer the fix, when it is issued, to NOT require unusual workarounds such as addition of the kernel to the aforementioned UPHCLEAN exclusions list.

 

I've upgraded to 650 and I continue to have the ID 6004 errors posted to the event log. The errors are indicating issues with the MRxSmb LANMANRedirector. The errors are occurring when I access off-line files while on-line with the server hosting the off-line files. Below is the full error entry.

Event Type: Error
Event Source: EventLog
Event Category: None
Event ID: 6004
Date: 5/5/2008
Time: 6:22:32 PM
User: N/A
Computer: JPFT40
Description:
A driver packet received from the I/O subsystem was invalid. The data is the packet.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 0c 00 e0 00 0e 00 00 00 ..à.....
0008: 00 82 b8 e4 06 af c8 01 .‚¸ä.¯È.
0010: 40 00 00 00 00 00 00 00 @.......
0018: 00 00 00 00 04 00 4e 00 ......N.
0020: 00 00 00 00 cb 0b 00 80 ....Ë..€
0028: 00 00 00 00 10 00 00 c0 .......À
0030: 00 00 00 00 00 00 00 00 ........
0038: 00 00 00 00 00 00 00 00 ........
0040: 4d 00 52 00 78 00 53 00 M.R.x.S.
0048: 6d 00 62 00 00 00 5c 00 m.b...\.
0050: 44 00 65 00 76 00 69 00 D.e.v.i.
0058: 63 00 65 00 5c 00 4c 00 c.e.\.L.
0060: 61 00 6e 00 6d 00 61 00 a.n.m.a.
0068: 6e 00 52 00 65 00 64 00 n.R.e.d.
0070: 69 00 72 00 65 00 63 00 i.r.e.c.
0078: 74 00 6f 00 72 00 00 00 t.o.r...
0080: 46 00 49 00 54 00 53 00 F.I.T.S.
0088: 00 00 4e 00 65 00 74 00 ..N.e.t.
0090: 42 00 54 00 5f 00 54 00 B.T._.T.
0098: 63 00 70 00 69 00 70 00 c.p.i.p.
00a0: 5f 00 7b 00 30 00 38 00 _.{.0.8.
00a8: 41 00 42 00 42 00 45 00 A.B.B.E.
00b0: 37 00 44 00 2d 00 39 00 7.D.-.9.
00b8: 41 00 32 00 43 00 2d 00 A.2.C.-.
00c0: 34 00 37 00 36 00 32 00 4.7.6.2.
00c8: 2d 00 42 00 30 00 41 00 -.B.0.A.
00d0: 32 00 2d 00 41 00 41 00 2.-.A.A.
00d8: 45 00 43 00 39 00 00 00 E.C.9...

 

I am one of the persons having trouble on servers which are NOT running the UPH clean service.

I also got version 3.0.653.0 from Marcos and it is running for about two weeks on one of the critical servers without causing any trouble

 

Yeah, see, this makes me very curious. I'd like to know exactly what was causing the trouble and what they did to fix it. I guess there are actually (at least) TWO problems. One with the UPHCLEAN service, and the other with some other component(s) in the OS. They needed to fix both. It appears that they've fixed the "other component" problem, and may still be working on the UPHCLEAN problem to fix it by some means other than excluding ekern.exe from oversight by UPHCLEAN. They might have to do that anyway since Vista and WS2008 both have features of UPHCLEAN incorporated in their User Profile Service.

Of course, a lot (as in almost all) of the above is pure speculation on my part. The folks at ESET are apparently working hard on this, but they aren't giving out a lot of detail about it.

 

jfreymann,

Yup, that's the one. I'm a little surprised. I don't recall reading about anyone seeing this error after upgrading to 3.0.650.0. (And I'm too pressed for time to read back through this thread, and others, to find out if my memory is faulty.)

Tell us, are you having any behavioral problems with that system (lockups, loss of responsiveness to logon requests or remote admin sessions, failed access to shares)? Which OS is it running? How, generally, is it configured -- DC, simple file server, etc.? Is it running UPHCLEAN? If so, have you excluded ekern.exe from oversight by UPHCLEAN? (I doubt the UPHCLEAN issue is related to the error message, but I'm just curious.)

 

The only functional impact other than the 6004 entries, is the Offline Cache gets corrupted about twice a week and I have noticed that Quicken can't automatically open the last file anymore. But that may be due to Offline files, though that began when I switched from McAfee to ESET SS a month or so ago. I've not "knowingly" installed UPHCLEAN. It doesn't show up in the Add/Remove Programs list.

The system hasn't locked up. I'm running current patches ("custom") on XP SP2, on a "ancient" IBM T41 with 2GB ram, and 1.3GB Pentium M. This is a very simple peer-to-peer XP environment, I'm a one man consulting firm, so not a lot of network activity other than file and print sharing.

Does that provide any insight?

 

Thank you for the information, jfreymann.

Yes that does satisfy my curiosity, not that that helps anyone else out much.



I wouldn't expect to see the really untoward behaviors on Windows XP since it's not really a server OS. (It seems that the symptoms on desktop operating systems have been much milder than those on the servers, for whatever reason.)

That information about Offline Files, though, is pretty disturbing. Have you communicated with ESET about that? I'm not sure it's related to the ESET software, but it would be nice to be sure that it isn't.

Insofar as UPHCLEAN is concerned, you'd have to download it from MS and install it -- not that it would be a memorable event. It's a very easy installation, and you don't usually hear anything from it again. It would be listed in the services.msc applet if it is running. It would be listed in add/remove programs if the automated installer was used for placing it on the system, but it would NOT be there if you had downloaded the manually installed version. On the other hand, the manual installation would stick in your memory (registering the service, etc.) -- unless you're old and forgetful like me, maybe.

Thank you again for the information.

PS: I also notice that you're using ESS. That might add a little complexity to the issues, too. I'm not familiar with ESS, so don't know.

 

I'm confident that UPHCLEAN isn't on my system. I'd remember installing it. Though my hair is getting grayer every day...

I'm confident the OFFLINE Files cache corruption is related to the ESS, I've been using the offline mode for several months without any events being recorded. The corrupted cache messages began the day that I installed ESS. And have continued 1 to 2 times per week since. And I've had at least 2 if not 3 versions of ESS installed.

I have not reported this problem to ESET, assuming that it is related to the 6004 issue.

 

I hope you'll report the issue to ESET. I know it can be bit of a pain to go through troubleshooting, but every little bit of information can be useful -- particularly if the type of problem you see hasn't been reported to them before. Sometimes the addition of a new symptom or symptoms to the matrix can shed a lot of light on a software problem.

Good luck!

 

Since I'm a newbie to ESET, how do I go about reporting this?

 

Look under Help and Support in the software. There are links to two methods of submitting a request for help. The software itself prepares an intial report. If tech support requires more information they'll contact you by e-mail and give you instructions.

 

We also have one server out of 3 so far that is experiencing similar issue (Windows 2003 Std server SP1) It needs to be rebooted every 3-4 hours or so. Never used UPClean on this server...

NOD is 3.0.650.0 latest definitions...

It is a file server with about 100 shares or so & is also a proxy server+WSUS... i.e. lots of TCP connections.

David

 

CrookedBloke,

I did report my OFFLINE files issues to ESET via the "Contact Customer Care" option on the help menu this evening.

 

Thank you! Like you, I imagine that your problem is probably a part of the general problem, but I wouldn't want to assume this was so. I was making some similar assumptions back in December that really wound up biting me in the butt!



Here's hoping the folks at ESET are able to get these issues sorted for us. The delay in deployment of version 3 has been a huge problem for me.

 

Even after completely disabling the Web & Email scanning options, our server still experienced issues responding to share requests. No event log messages, Server is still working via RDP sessions...

After talking to eSet support here is what the recommended options are:

• Real time file system | Uncheck Network drives
• Web access protection | Enable
• HTTP enable http checking
• Web Browsers - uncheck all except for iexplore.exe (or firefox in some cases.)
• Protocol filtering | Applications marked as Internet browsers and email clients

There is an article with a few other options recommended for servers shown here:

http://training.eset.com/kb/index.php?option=com_kb&Itemid=29&page=articles&articleid=727

I'll report back to see if that made a difference.

David

 

I'm unhappy to say that after the changes we put in place per NOD32's support the server has stopped responding to file share requests twice...

At this point we had no choice but to remove NOD32 and ponder what's going on... On 4+ other servers / 76+ workstations we've not had such problems, so I'm wondering what else we're missing.

David

 

I'm afraid I can't say that I'm surprised. This is an astonishingly stubborn problem. We had to revert from 3.x to 2.70.39 on all of our systems -- except for the test server that runs 3.0.653.0. That one seems fine, but I can't deploy a test fix on my production servers.

Thank you very much for reporting your findings.

 

FYI:
We just had to move back down to v2.70.39 on our Windows 2003 servers. There was something in v3.0.650 causing the servers to no longer allow write access to the shares after some random point in time.

We never could determine exactly what was happening as there were never any errors in any logs (Windows or NOD), but as soon as we moved back to v2.70.39 all is well again.

Vidmo

 

I've been reading/pondering about that exact solution after reading other threads discuss similar issues.

Just curious: has anyone trying restarting the Server service?

David

 

None of our server have UPH clean service installed, from our point of view it seems moot when no regular users are actually logged on to it. We only use administrative account logons on the servers.

We have suffered from the lockup issue on at least 3 of our servers 2 domain controllers and 1 file server.

However we have installed and closeley monitor servers with the 650 version and sofar we haven't had a lockup for the entire time it's been installed now, (at least a month).

/Göran

 

I guess you did restart the system after you upgraded it ?

/Göran

 

There is a way to reset the offline files cache it can get corrupted by other means then by EAV aswell. try http://support.microsoft.com/kb/230738

Regards Göran

 

In our case I reboot when I remove the previous Anti virus product, then reboot after installing NOD32...\


RE: MS KB 230738
We have completely shut off Offline files via GPO on all servers/shares/drives/workstations...