Changed memory, now have crashing issues

[bizz & buzz]

Hi,
A few day ago I upgraded the memory from 1 GB (single stick)
to 4 GB (2 sticks). Since then AvsP keeps crashing every time I rapidly flip tabs in it. How can this be fixed? :confused:

System:
Motherboard: Foxconn 945 7MD
Cpu: Core 2 Duo E4300
Memory: Kingston 4 GB DDR2
OS: XP SP3

[IanB]

Memtest86+ (http://www.memtest.org/)

[BigDid]

Hi there,

If your MB has 4 memory slots (and it seems the case) you may want to check that you did use slot 1 and 3 not 1 and 2 aka 2 slots of same color?
If ok, check one dimm on slot 1 at the time.

Did

[bizz & buzz]

@ IanB
I let MemTest86+ to work for 4.5 hours thereby completing 4 passes. no errors at all.

@ BigDid
You right I do 4 memory slots. sticks are on slot 1 (yellow) and slot 3 (yellow). Is that what you meant?

[Didée]

Complex Script? AvsP breaking the 2GB barrier on x32 Windows?

[LoRd_MuldeR]

Memtest86+ (http://www.memtest.org/)

Another option, at least on newer Windows, would be:
Start -> All Progarms -> Administrative Tools -> Windows Memory Diagnostic

[Didée]

Well, Windows' memory dignostic is similar to Windows' experience index: it does something, but nobody knows what. It's a pitch-black box.
(You know, the answer to life, universe and everything is "42".)

[BigDid]

@ BigDid
You right I do 4 memory slots. sticks are on slot 1 (yellow) and slot 3 (yellow). Is that what you meant?

Yep, good.
Now you can test each memory dimm in slot1 to verify that you do not have 1 dimm faulty (it can happen quite often).
If faulty, verify visually the contacts of the dimm, they should be shining and without spots or stain; you can always rub the contacts with a a soft rubber for pencils to make them shine again.

I second the other suggestions specially problems happening only when breaking the 2gb barrier when the second dimm is used!

did

[LoRd_MuldeR]

Well, Windows' memory dignostic is similar to Windows' experience index: it does something, but nobody knows what. It's a pitch-black box.
(You know, the answer to life, universe and everything is "42".)

Well, it's yet another option to test at least ;)

If it runs through without error, you don't have any guarantee for anything. But if it detects an error, you know there is a problem with your memory.

@bizz & buzz:
I would also suggest to remove the new memory and check again with your previous configuration.
Just to be sure that this is really related to the new memory and not "something" else that just started at the same time by chance.

[IanB]

@ IanB
I let MemTest86+ to work for 4.5 hours thereby completing 4 passes. no errors at all.

@ BigDid
You right I do 4 memory slots. sticks are on slot 1 (yellow) and slot 3 (yellow). Is that what you meant?Seeing MemTest86+ gave the thumbs up, 4 times, the memory installation is probably okay.

With regards to slot assignment, it is mother board specific. Some boards interleave adjacent slots, some interleave alternate slots, some don't interleave, some don't work when it is not the way they expect.

The speed numbers on the left of MemTest86+ are what is really happening. You can quickly check the speed of each combination of slot assignments to see if any one gives a performance boost due to interleaving compared to the speed when only 1 single dimm is installed.

As to your problem, it now sounds more like address space related. Try using SetMemoryMax(128) or 64 to restrict the size of the frame cache. If that helps try big values like 1500 or 2000 to try to force the fault to occur. Check the VM size of the process in Task Manager with the various scenarios, if it gets near 2GB then you can expect trouble.

Some filters allocate large amounts of memory independently of the frame cache, SetMemoryMax() will not control these.

[Robert Martens]

You might also try Prime95 (http://www.mersenne.org/freesoft/#newusers, skip Step 1, just download the version for your OS). The Torture Test helped me recently, when I ran into a similar issue and couldn't quite narrow it down with memtest. "Blend" does a mix of CPU and RAM testing, according to the docs, and "Small" does mostly CPU cache, very little RAM, which I found useful.

After building a home backup server with spare parts I had lying around, I'd get STOP errors after only a few minutes of network file copy activity. The error codes and a little Googling pointed me toward the RAM or hard drive, so I tested the memory and got errors. This is an old Athlon XP, DDR setup, and I had three sticks of RAM in, so I removed them and tested each one individually. All passed, so I instead disconnected one of two hard drives, that itself had been giving me problems (wouldn't complete a format in Disk Manager). This seemed to help. Memtest showed no errors, even with all three modules installed, and the system would last longer before failing, but eventually it would still start throwing the same errors. Even after trying known good RAM from another system, I'd get the crashes.

According to the memtest documentation, errors may be related to memory modules, CPU, or the memory controller, and since I had no way to explicitly test only the controller, the only remaining option was the processor. The Prime95 torture tests would all fail, and "Small FFTs" failed within moments of starting, which to my layman's mind suggested there hadn't been much RAM activity, and that the CPU was actually at fault. This may have been a leap in logic, but removing, regreasing, and reseating the processor helped a bit. Memtest reported no errors, even with all three sticks of RAM, and Prime95 lasted for six or eight minutes, but still eventually failed. If I tried to use the system to backup any files, it started with the STOPs again.

After days of screwing with hardware swaps, running crash dumps through WinDebug (http://www.microsoft.com/whdc/devtools/debugging/default.mspx, very useful, if you can get the symbols configured correctly; !analyze -v is a big help, and !analyze -v -hang helped me with a USB device-related lockup on my main video editing system not too long ago), I finally got around to trying what I'd thought was the least likely culprit and replaced the power supply.

The system's been rock solid for the past two weeks. The original three sticks of RAM are back, as is the problematic hard drive (which completed the format and is now in regular service), and Cobian Backup is remote booting, copying files to, and remotely powering down the system, without issue.

My case was unique, in that the power supply is one that had been sent in for repair after failing inside of six months of its purchase (I suppose I should have been more suspicious of a refurbished unit), so it may very well not be the problem in your situation. I think it's worth keeping in mind, though; every now and then you hit that outside chance.

[Ghitulescu]

Memory chips are rarely defective themselves, usually it's a problem of communication (see also the timings in BIOS) and/or compatibility.

[bizz & buzz]

Thanks for all your help guys, much appreciated!
At the end it wasn't any hardware problem, but as you suspected, the 2GB barrier on x32 Windows.
It crashed whenever virtual memory exceeds ~1850MB (in both the new and the old memory configurations).
Using SetMemoryMax() in each of the simultaneously open scripts so that the overall memory usage will be restricted to less then 2GB did the trick.
Love this place, :thanks:

[Emulgator]

BTW, I can second Robert Marten's experience for a MicroTower PC
which does MPEG-4 encoding day and night for a surveillance system:
One fine day this thingy got unstable, graphics faults, stalled startups etc.
RAM checked, Graphic cards swapped, CPU and/or controller in doubt. No really weak spot found.
Just because a bit later the Power supply as well began to not start up everytime properly,
I replaced the power supply, and: Success: All was stable again. Just PSU Capacitors starting to degrade.