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

Well, let's hope not!

During the diagnostic process I gather (from a comment by Marcos and a reminder by ablat) that ESET developers trying turning off a protection feature to see if it was the culprit. Assuming that feature was an important one, I would hope that the eventual fix would involve something other than just turning it off.



Yeah, my paranoia is running away with me, a little.

 

Hi, Mark.

Unless UPHCLEAN were installed manually instead of using the .msi version, it would show up in Add/Remove Programs. To be absolutely sure it isn't running on your system you could check services.msc. It would be listed in there.

Sorry I can't tell you whether or not the new test version works with SBS. Don't have any of those here. My guess would be "yes", but there's only one way to know for certain.

Yeah, I know. When I screw up I idle a work force of a couple hundred people and shut down three big buildings. Fun times, I tells ya!

 

I assure you I meant performance wise, although it did cross my mind a couple of times!! I remember the post re: disabling one of the new features in one of the test drivers we had, I hope they have re-enabled it, however, they didn't say which feature had been disabled, so I assume there is no way for us to check...

PS, still very happy with the performance of this new test/patch release...

 

No feature was disabled in the version you're testing We've merely added a new mechanism that should prevent this kind of problems from happening.

 

Hi Marcos

Any more technical details on the problem
I would like to understand whats going on for my own peace of mind.

Also could you clarify if the issue we are talking about now is a different issue to the title of this thread (Event ID:6004 - A driver packet received from the I/O subsystem was invalid.) or is it all part of the same issue.

Thanks

Mike

 

Thanks for giving us a little "peace of mind", Marcos.



I, too, am curious about the mechanism of this problem. I'd like to know if the developers think there is any downside to the use of UPHCLEAN on systems running EAV 3. I have employed it since it became available as a hedge against software and drivers which might cause problems by failing to release handles on the user profile hive when logging off.

Until this case with EAV 3, I had never run into any software which caused a problem in conjunction with UPHCLEAN. In fact, UPHCLEAN was a nice safeguard to prevent trouble.

I'm also curious to know if the developers are planning for users of UPHCLEAN to continue to have to place an exclusion for ekern.exe in UPHCLEAN's parameters location in the registry, or if future versions of the fix will make it possible to operate without that exclusion in place.

Thank you for any information you can provide to us, Marcos. I'm very happy that progress has been made.

 

I'm glad to see there is real progress being made to get the initial and subsequent issues resolved.

If you are still looking for testers Marcos, I'm very interested in getting a copy of the test version.

Dan

 

That's exactly what we wanted to hear, thank you. May we ask what mechanism?

Ditto

 

Running 2003 Enterprise R2 here...

Any ETA on general availability of this fix? Had 4 server lockups in 48 hours and have since moved back to 2.x on that server. No issues in the last three weeks post change.

 

Hmmm, just had something interesting happen... I got a phone call saying that one of our servers was slowing to a crawl, I was in the DPM console at the time, so checked the status of the agent, the protection agent was showing as unavailable, the server was responding to pings, login via RDP was slooow, but got there eventually. I logged onto the server (after about 10 minutes of waiting) and discovered that the server had 3.0.642 installed (was missed by someone!!) the memory usage for ekrn.exe was at 65,180kb, and slowly climbing. ESET reported that it had scanned 4,594,455 files, so had been fairly busy! I forced a process kill on ekrn.exe (not the preffered option, I agree, but as the server is a fair distance from me, I couldn't risk the server locking completely) the ekrn.exe reloaded immediately (as expected) but this time memory use fluctuated a little, then settled on 29,569kb used. Performance returned immediately, the DPM agent reported as OK within seconds of a refresh in the console.

I wonder, Marcos, is this related to the issues with 3.0.x? The ekrn.exe process appeared to not be releasing files/resources after scanning them, I'm hoping you'll say "yes, we noticed that and have fixed it" I am not running UPHCLEAN on any of my servers, unfortunately, this has not had the scroll-scroll-r-ctrl option added to it, so I was unable to get a memory dump for you to analyze.

 

Hi Colditzz,

no, there was no problem releasing files. It was not a bug as such, the problem was caused by the way server OS work under certain circumstances so we made a workaround for it. After we make some additional changes to the code, we'll test and release newer installers.


Marcos

 

Thanks for the reply and explanation Marcos. I look forward to testing a release version soon... Please, if possible, PM me when this is available.

 

Can I confirm that even with 3.0.653 the ekrn.exe still needs to be added to the USER_EXCLUSION_LIST Reg_Multi_SZ key for the UPHClean service?

Long story short, I was contacted by one of our site admins yesterday, stating that they were having issues with their server, they were running 3.0.621 (heaven knows why since I'd made a point of getting it removed from every server we have! but it is in a seperately managed forest) so I think to my self, a perfect opportunity to test 3.0.653 on a known problem server... I install it, and lo and behold 22 hours later, the server has hung again... I ask some questions about the on-site administration of the server and discover they are using RDP, a lightbulb flickers in my head and I ask the question about UPHClean, and I get, "oh yes... we installed that a few months ago... any reason?". So, hence the question above, even with 3.0.653 installed on this server, it IS running UPHClean (un-beknown to me ) and it still suffered the lock up... I have added ekrn.exe to the exclusion list and put the R-Ctrl-Scroll-Scroll entry in the registry incase it occurs again, but thought I'd ask the question here.

 

I'm pretty sure that's the case, Colditzz. I'm actually placing ekern.exe in the PROCESS_EXCLUSION_LIST, rather than the USER_EXCLUSION_LIST -- just because it makes more sense. It works when ekern.exe is put in either parameter. After placing ekern.exe in the exclusion parameter you have to stop and restart the uphclean service, IIRC.

 

Thanks for the speedy reply CrookedBloke, I'll leave it in the USER... for the time being, if it hangs again, I'll move it to the PROCESS... instead, I warm booted the server just to be safe Have a good weekend...

 

Ha-hah. I just tried to reply by typing "U2" and hitting the Submit Reply button. The forum software doesn't like that stuff, I guess.

So, here's my reply --

You, too! (have a nice weekend)

 

Lol... I did, and hope you did too. As far as I'm aware, the server is still stable \o/ so thank you for the quick response CrookedBloke.

 

Hi, Colditzz. Yes, my test server has been hammered just like one of my production servers ever since I stuck 3.0.653.0 on it. Not a single glitch.

I wonder if everything is okay in Bratislava. Looking forward to an official release I can roll out to my domain.

*sound of crickets*

 

Ditto... My test server has been sitting there quite happily for the last couple of weeks, and it now seems that the live server is 'happy' too. I just hope this is going to be released soon...

Any eta yet Marcos?

 

Hello,
I am also hoping that .653 is released soon.
Any news?

 

Don't be surprised if the release is a later build than 3.0.653.0. I think that the ESET developers are probably going to want to go beyond having to have the user exclude ekern.exe from oversight by uphclean. Or I suppose they could handle the issue by making that registry change at installation time. But I think that the design philosophy I think I see in ESET's products has always indicated a preference among their developers for avoiding invasive or workaround behaviors in their software.

It should also be noted that it's possible (probable?) that the responsiveness issue(s) are not entirely associated with uphclean.

As anxious as I am for a version 3 I can roll out to my production network, I'm hoping that ESET takes as much time as they need to really get this thing nailed down. I'm feeling hopeful about it.

 

Well 3.0.657 was just released today, but the English language installer has not been posted yet. But if someone speaks Slovenian, maybe they can test it!

 

There is some confusion with version numbers and languages. In the past I have seen a new version number just for a language release (no functional changes). Prehaps ESET can confrim whether this is a new functional version or just a different langauge version. (very confusing I know).

Thanks

Mike

 

They also need to keep the fixlist up to date. 650 has been up for a while yet the fix list is only current as of 642. And now 657 is rolling out....

 

Any news from eset when we can expect to see a new release with a fix for this problem? I been waiting for ages for this to be fixed and is the reason why i decided to not give 3.0 another shot.