POSReady 2009 updates ported to Windows XP SP3 ENU

[MagicAndre1981]

yeah the MULTIPLE_IRP_COMPLETE_REQUESTS BSOD comes from symantec.  The other is a memory corruption wile overwriting the free memory with Zeros so that it can be used again:

********************************************************************************                                                                             **                        Bugcheck Analysis                                    **                                                                             ********************************************************************************PFN_LIST_CORRUPT (4e)Typically caused by drivers passing bad memory descriptor lists (ie: callingMmUnlockPages twice with the same list, etc).  If a kernel debugger isavailable get the stack trace.Arguments:Arg1: 0000008f, The free or zeroed page listhead is corruptArg2: 0008679f, new pageArg3: 000763ff, old pageArg4: 00000000, 0Debugging Details:------------------BUGCHECK_STR:  0x4E_8fCUSTOMER_CRASH_COUNT:  1STACK_TEXT:  nt!KeBugCheckExnt!MmZeroPageThreadnt!Phase1Initializationnt!PspSystemThreadStartupnt!KiThreadStartupSTACK_COMMAND:  kbFOLLOWUP_IP: nt!MmZeroPageThread+13080528529 cc              int     3SYMBOL_STACK_INDEX:  1IMAGE_NAME:  memory_corruptionFAILURE_BUCKET_ID:  0x4E_8f_nt!MmZeroPageThread+130

Are the RAM timings fine?

[dencorso]

@MAgicAndre1981: Dave-H's machine is a 2 Xeon Supermicro X5DAE with 4 GiB ECC DDRs, and has been working OK for quite a long time already... I don't believe it can be memory timings, unless he's decided to tweak them recently.

 

@Dave-H: I'd give the machine a good old 12h or more run of MEMTEST86+, just in case: it may have been just a quirck, but it may be RAM begining to malfunction... and if so, MEMTEST86+ will show it, and help find which stick is the problem, too.

[Dave-H]

Thanks guys!

Touch wood, the machine seems to be running fine again now.

I will certainly do the memory test if I get any more problems, but I would be very surprised indeed if it was failing RAM that caused the issue.

It would be an amazing coincidence if it happened at the exact time that I installed those patches!

It is odd that the patches all appeared to install with no errors, and then a sudden spontaneous BSOD occurred quite a while later after a successful reboot.

I wasn't even actually using the machine when the first stop error happened, although there had been a lot of disk activity up to the point at which it crashed.

I didn't see what the machine was doing when the second stop error occurred as I wasn't with it when it happened.

[dencorso]

You are right that the .NET updates can defer optimization for later and will then wait for moments in which the machine is mostly idle to do their work. So it's not unusual to have system activity for sometime after a .NET update is applied, even with one intervening reboot or shut down...

[Dave-H]

Thanks den, yes I said earlier that I was a bit suspicious of the .NET optimisation service, which would almost certainly have caused the disk activity and the sluggish startup with the firewall error. I've seen that happen before after .NET updates.

submix8c said he always disables it after any updates, but I guess it's there for a reason, and its impact on the system is only temporary.

Just on this occasion, it may have generated the first crash, which may in turn have caused the second.

Chkdsk ran after both crashes as you would expect, and although it didn't record fixing anything apart from the usual few truncated and cross-linked files that you always get after a stop error, it may have sorted it out.

Still keeping my fingers crossed!

I have updated Symevent BTW.

Cheers, Dave.

[submix8c]

Well, AFAIK, ".NET  Runtime Optimization" is only worth a diddly for .NET Applications that you run. The sad part is that it's run as a SERVICE and occasionaly runs (NGEN) just to find out if you have added new .NET Apps. This, IMNSHO, is rather, shalll we say, they height of igorance"? See this reference (and links within) -

http://social.technet.microsoft.com/Forums/windows/en-US/a3107fff-8e61-48bd-8c3e-77afab7715d2/net-runtime-optimization-services-causing-high-cpu-usage?forum=w7itproperf

In particular THIS link -

http://blogs.msdn.com/b/dotnet/archive/2013/08/06/wondering-why-mscorsvw-exe-has-high-cpu-usage-you-can-speed-it-up.aspx

Millions of software developers around the world choose to write apps using the .NET Framework, which is provided by Microsoft. You’ve probably used many apps built with the .NET Framework without even knowing that. The .NET Framework includes a technology called Native Image Generator (NGEN) that makes apps launch much faster and that periodically does work to optimize your machine.

THAT, my friends, is why I IMMEDIATELY Disable the (so-called) Service after NET Updates. It has a nasty tendency to clobber your computer. I had a heck of a time figuring out what was "temporarily) bashing me and how to stop it. And YES it was causing my Symantec AV all sorts of heck (interrupting it), as well as other stuff. THAT is the EXACT reason I turn off Symantec Real-Time unless I have some reason to use it. As far as I'm concerned, MS is just as guilty as Symantec (and other vendor) Real-Time scanners. Dumb, to say the least (ref the NGEN thingy above).

 

Question - just how many NET apps do you have installed - ON XP? Bet not many... So, what's the point of "optimization" for a handful (like nLite)?

 

Just my opinion. You do what you wish. But (apparently) next time you update dotNET you'd better totally disable any of the Symantec Services so the NGEN part can run - After Install, go to Safe Mode and Disable ALL Symantec, reboot and let dotNet "optimize", then reset the original settings for Symantec Services.

 

NGEN -

http://msdn.microsoft.com/en-us/library/6t9t5wcf%28v=vs.110%29.aspx

 

HTH

[DarkRats]

The problem is most likely caused by the patched update.exe file. I was not sure at first but the issue seems to be present in any machine with Norton software installed.

 

I will try to cook up a more "clean" patch which will not cause this memory address conflict. The update.exe file uses the standard IsInfFileTrusted patch. This patch has been used since 2005, when Gurgelmeyer created USP5. But there are other ways to achieve the same result. These patches may not suffer from this problem.

It's interesting that you thought it might be caused by the update.exe file. My computer BSOD'd as soon as the file was run, and even before any new files were written to their locations. Not only that, but the other day I had downloaded a custom SP4 update, to try it out, and it too crashed my system immediately after the files had been extracted to a temporary location. In both cases, I suspected the installer was part of the problem. It would be very nice if you could find the cause and then create updates that didn't conflict with Symantec. I'm always thankful for users, like harkaz, who have the skills to modify installers etc.

[harkaz]

There is a new update.exe I patched. It might fix the Norton issue in older symevent.sys versions.

 

The latest version of symevent.sys (12.9.5.2) has no issues with the update.exe file.

[Atari800XL]

Thanks harkaz, can you tell us which modifications you made (and maybe where this particular version is from)? So we can apply the changes to localized versions and/or for "safety"'s sake? Thanks!

[bphlpt]

In fact if you would post a complete tutorial how update should be modified, probably over at RyanVM, that would be great.

 

Cheers and Regards

[Dave-H]

Thanks harkaz, can you tell us which modifications you made (and maybe where this particular version is from)? So we can apply the changes to localized versions and/or for "safety"'s sake? Thanks!

Yes, I'd be interested to know as well where that later version of symevent that you mention came from.

The latest version on the Symantec FTP site is 12.8.6.38, which I installed thanks to submix8c.

If there is a later one I would want to install that of course, assuming that it is compatible with XP!

A search for version 12.9.5.2 doesn't find any downloads available for it.

Edited May 19, 2014 by Dave-H

[harkaz]

 

Thanks harkaz, can you tell us which modifications you made (and maybe where this particular version is from)? So we can apply the changes to localized versions and/or for "safety"'s sake? Thanks!

Yes, I'd be interested to know as well where that later version of symevent that you mention came from.

The latest version on the Symantec FTP site is 12.8.6.38, which I installed thanks to submix8c.

If there is a later one I would want to install that of course, assuming that it is compatible with XP!

A search for version 12.9.5.2 doesn't find any downloads available for it.

 

 

It's from the latest version of Norton 360.

I just tested the update.exe in VM with Norton Antivirus 2003. An older version (11.0.1.1) of symevent.sys works fine with the new update.exe.

 

Here is the file:

 

https://drive.google.com/file/d/0B7k-l_4omFECajNuQms0OGZObXc/edit?usp=sharing

 

Please test it on your system, I've been unable to reproduce your problem so far.

Edited May 19, 2014 by harkaz

[Atari800XL]

Well, I was talking about update.exe, and how you modified that.Never mind, don't want to complicate things.

 

Please remind me: is there only one "update.exe", or are they localized as well? In that case, please tell us how you modified it.

Edited May 19, 2014 by Atari800XL

[harkaz]

@Atari800XL I will answer your question, but let's see first if the problem is fixed.

 

Yes they're localized. I will give you a generic approach to patch update.exe.

Edited May 19, 2014 by harkaz

[Atari800XL]

Thank you harkaz, all clear now. Sorry, don't want to rush you, please take your time.

I never thought I'd get all this working anyway, so you're my hero already...