dencorso

Yeah. And if you want the best possible stability and performance, you should cut short your own suffering and adopt RLoew's patches.

There is a generic vídeo driver patched by Tihiy, which is capable of 1024x768x256, IIRR. I'll locate it and update this post soon. It's here.

This ring any bells? Blessed be ramateja.g, for being hard at work for the benefit of many!

I'm not home right now, so I cannot check it, but, IIRR, one has to use RPM 2.43 or 2.44, *not* 2.40, to work successfully with SATA HDD's...

With all due respect to all involved, let's face the facts: considering that the real problem is to create a generic (or Intel specific) USB 3.0 or USB 3.x for Windows XP, that any XP USB 2.x driver cannot be construed as W1, because USB 3.x and USB 2.x are very different animals, it's easy to deduce no W1 ever existed. On the other hand, if W1 did actually exist, W2 wouldn't be necessary at all. Therefore, as I said before, this is an ontologically impossible task.

Some one may, but I doubt it: ontologically impossible tasks use to be the most difficult to perform, you know.

The main point of Usher's Method is having access to Sae Mode with > 1 GiB RAM So, since SYSTEM.INI is ignored, when entering in Safe Mode, it's necessary to also edit SYSTEM.CB, which is respected, when entering in Safe Mode. In fact, it works brilliantly for more than 512 MiB to about 2 GiB. With > 2 GIB the system gets more and more unstable, if only using the MaxPhysPage and MaxFileCache directives, without any patched files... although some machines will boot and work for some time, before giving one an BSOD. himemx.exe will delay more the BSOD, in the same conditions, byt only the RAM Limitation Patch is able to deliver a really stable system with > 2 GIB RAM, in my experience (and my list seems to support this as well).

Of course, jaclaz is right (ain't he always?) !

http://www.theregister.co.uk/2017/08/11/rodents_destroy_internet_in_south_london/

By the same token, all settings in about:config are CaSe SeNsItIvE!!! Please do check that, too.

Well, a 2TiB (2 199 023 255 552 bytes) limit if sector size == 512 bytes means a 32-bit sector count. In such a case, by adding 1 to 2TiB, the carry slides into oblivion (= has no place to go) and the counter wraps-around to zero. That's math. There's no avoiding it.

What about the carry big sliding into oblivion? UEFI_Drive_Partition_Limits_Fact_Sheet.pdf

The upadates we got this month are for jet and t2embed (both of which did not receive updates since way back when) and would not put in risk the stability of your system, besides the more usual win32k.sys which can do that, and one more... query.dll, IIRR. These later two are single file updates, so that later today, when I get home, or tomorow, at the latest, I can give you size, version, md5 and sha-1 so that you can test their integrity.

Glad to see you've reached acceptance, mr. OP !!! AFAICS, yes. And no report of any issues, so far!

Ditto for XP. And Sandy or Ivy Bridges are still pretty powerful for day-to-day use and much less expensive than razor-edge hardware.

Try RLoew's nVidia Fix before giving up. It's free and it's on this forum for download. I don't remember where, exactly, but some other old timer here sure will point you to the right place. Success in your set-up seems to me to be just around the corner, right now. Later addition: it's on this post.

Thanks for the Coreinfo output! It eliminates some hypotheses I had. Then again, it also show you're using an AMD Phenom(tm) II X4 940 based machine. As it happens, I do have one machine based on the selfsame processor and a rather old motherboard (a M2NPV-VM board with 8 GiB RAM), having an onboard GeForce 6150, and FF 52.2.0 esr with the @mixit tricks displays HTML5/H.264 video just fine! So, I'll ask you to kindly perform just one more test, please access this test page and see whether all 3 videos display OK for you or not. TIA.

The slowest of my current multicore machines (an AMD Phenom II X4 940 Black Edition, with 8 GiB RAM, so not so slow, in fact) got the list in precisely 1 min !!! And it found a definitions update for MSE, on top of it... Yeah: no Office updates, the fastest scan in more than one year !!! Even so, I too find strange no IE8 Cumulative Update... then again, it's not the 1st time this happens, but it's unusual, all the same...

The old and always reliable wraparound strikes again...

Try the original Unknown Devices.

My friends, IMO it's not mature yet. In any case, please do read this thread. With 8 GiB one can create a RAMDISK and then put the swapfile in it, the rest can be used to hold the Temporary Internet Files, and the caches for FF, Opera and Chrome: and it'll get auto cleaned up at every reboot.

The Office 2007 compatibility pack and its updates also does cause the same issue.

The 100% CPU usage itself is just another symptom, not the true issue. On multicore CPU usually it can use 50% of two cores, and yet not finish looking for updates after mor than 17h !!! However, if one patiently finds by hand all the missing Office updates and then applies them manually (usually it's not too tedious, since most don't require rebooting), then the MS Update works as intended and finds all other needed updates in 2h or less. This is equivalent to use the Windows Update site instead, because that site does not search for Office updates, but it has the advantage that, once done, one has the Office up-to-date and, usually, if applying updates once a month, the new Office updates dont cause the issue again or, when they do, it's just a matter of applying just a few new Office updates by hand. AFAIK, up to now, nobody found out which Office updates do cause the delay and which don't. It seems that any Office versions do cause this issue, regardless of which Office it is. This is all I currently know about this issue.

@Mac: Please do get coreinfo, redirect its output to a text file, zip it and attach the zip to your next post. TIA.

As you all fully know, the relevant dates, according to MS are: