(0xC0000005) STATUS_ACCESS_VIOLATION any idea what caused it?? Or what it exactly is describing?? Internet searches find nothing.

Message boards : Number crunching : (0xC0000005) STATUS_ACCESS_VIOLATION any idea what caused it?? Or what it exactly is describing?? Internet searches find nothing.
Message board moderation

To post messages, you must log in.

Previous · 1 · 2 · 3 · 4 · 5 · Next

AuthorMessage
Profile Keith Myers Special Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 29 Apr 01
Posts: 13161
Credit: 1,160,866,277
RAC: 1,873
United States
Message 1926946 - Posted: 28 Mar 2018, 20:30:46 UTC - in response to Message 1926940.  

I've been looking for 3805. I can't find it. I saw posts in the forums that it was coming. I think anything other than 3803 would be an improvement. I got burned with 3803. Should have stuck with 3204. But then I got trapped into 3803 with its AGESA and couldn't roll back. I never have had the courage to try the AFUDOS DOS BIOS load to get back to a previous AGESA level.
Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)
ID: 1926946 · Report as offensive
Profile Karsten Vinding
Volunteer tester

Send message
Joined: 18 May 99
Posts: 239
Credit: 25,201,931
RAC: 11
Denmark
Message 1926947 - Posted: 28 Mar 2018, 20:40:07 UTC - in response to Message 1926946.  

Yeah, I wish I had stuck with 3401, which was rock solid reliable for me.

Now I'm hoping 3805 proves just as good.

I can't remeber what board you are using, but I'm sure 3805 is released for it soon.
ID: 1926947 · Report as offensive
Profile Keith Myers Special Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 29 Apr 01
Posts: 13161
Credit: 1,160,866,277
RAC: 1,873
United States
Message 1926950 - Posted: 28 Mar 2018, 21:07:26 UTC - in response to Message 1926947.  

Just read through the last 4 pages of my board thread. Hadn't had the time trying to get the i7-6850K system running again. I have the Prime Pro. Just found 3805 in the Win7 32bit category at ASUS. Not any conclusive results about better than 3803, just different. One comment has me intrigued is that with these new AGESA BIOS', that Sammy B-die needs to have ProcODT set for 48 ohms instead of 53.3. ohms like before for 3200Mhz and Fast timings.

Also rumors that that 3907 is imminent in a few days too. I still think I will try out 3805 in the meantime. Probably isn't any worse than 3803 and at least can revert to 3803 if I need to this time.
Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)
ID: 1926950 · Report as offensive
Profile Karsten Vinding
Volunteer tester

Send message
Joined: 18 May 99
Posts: 239
Credit: 25,201,931
RAC: 11
Denmark
Message 1926958 - Posted: 28 Mar 2018, 21:41:35 UTC - in response to Message 1926950.  

I'll keep the ProcODT setting in mind, if this proves to still be unreliable.

I'm also hopefull for 3907 :)
ID: 1926958 · Report as offensive
Profile Keith Myers Special Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 29 Apr 01
Posts: 13161
Credit: 1,160,866,277
RAC: 1,873
United States
Message 1926974 - Posted: 28 Mar 2018, 22:52:43 UTC - in response to Message 1926958.  

In the process of stress testing 3805 now. Seems the same as 3803. But I am running the 48 ohm ProcODT right now. Got past stressapptest fine for the memory. Usually blows up in OCCT because of the high wattage runs. But that is the worst case scenario at 165W and if it gets past OCCT, it usually means that it will be stable in BOINC at normal 135W dissipations. Will see.

I see the BIOS has a build date of all the way back to 6 March. Sure takes ASUS a long time to test it in house before releasing. The 3907 will surely follow within a couple of weeks if the past is anything to rely on. ASUS seems to do that a lot, release back-back BIOS' within a week or two of each other, then a long 3 month long drought. The 3803 BIOS was from January.
Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)
ID: 1926974 · Report as offensive
Profile Keith Myers Special Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 29 Apr 01
Posts: 13161
Credit: 1,160,866,277
RAC: 1,873
United States
Message 1926983 - Posted: 28 Mar 2018, 23:28:47 UTC

Back to crunching BOINC. Passed OCCT fine. Will see how it does in the real world. Still on Safe 3200 settings for the RAM. It it flies through the night, I will attempt tightening back up to CL14.
Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)
ID: 1926983 · Report as offensive
Profile Keith Myers Special Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 29 Apr 01
Posts: 13161
Credit: 1,160,866,277
RAC: 1,873
United States
Message 1927013 - Posted: 29 Mar 2018, 3:03:14 UTC - in response to Message 1923977.  

I don't think the Microsoft OS has any knowledge of GPU memory: it will be referring to system memory. That page describes a coding file called 'ntstatus.h', which has existed since, well, the beginning of Windows NT.

Go up a level, and look at https://msdn.microsoft.com/en-us/library/cc231200.aspx. Your error has severity 'C' (for error), and code 5 (a very, very, early number in the grand scheme of things). It was probably defined in the very first draft of Windows NT.

Note the final part of the explanation: "The memory could not be %s." That %s could be replaced by 'written' - it could be a security protection error. I suggested testing RAM because it's relatively easy for the end-user to do, but from what you've said now, I agree it's less likely to be the problem. Is that machine up-to-date with security patches?

Well I trashed 341 tasks yesterday burning through my bunkered tasks for the outage all with too many exits. Seems the nvidia compute cache at C:\Users\Keith\AppData\Roaming\NVIDIA\ComputeCache got corrupted. All the errors were caused by not loading the OpenCl resources.

Deleted all the folders in the directory to clean things up and get tasks running again properly. Anyone know why the ComputeCache gets corrupted?

All the gpus are running stock in P2 state caused by the normal Nvidia restriction on compute work. So not overclocked in anyway. Cards are running cool since they are water cooled.

I see I have another status access violation error added to that bunch of trashed work today. I still can't figure out what is causing the issue. Only BOINC is throwing any kind of error. The memory has been checked 15 ways from Sunday. I can pass 3000% coverage of all 16GB of memory in testing with no errors. I can pass hours of Prime95 and OCCT stress tests with no errors. Yet BOINC throws errors.

Other than completely rebuilding the PC with a different processor, motherboard and memory and power supply, I don't have any other way of diagnosing what is causing the BOINC errors. This is VERY frustrating. The problem started with the cpu RMA swap. Really bad choice on my part it seems.
Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)
ID: 1927013 · Report as offensive
Profile Karsten Vinding
Volunteer tester

Send message
Joined: 18 May 99
Posts: 239
Credit: 25,201,931
RAC: 11
Denmark
Message 1927014 - Posted: 29 Mar 2018, 3:11:10 UTC - in response to Message 1927013.  

I understand your frustration.

Not being able to find the cause of instability is irritating.

My PC chose to reboot while I slept, I was awakened by the Windows logo/theme music...
So its not stable here with 3805 either. Though I did get a relatively long uptime.

I have tried setting 48 Ohm ProcODT now, will se if that helps.
ID: 1927014 · Report as offensive
Profile Keith Myers Special Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 29 Apr 01
Posts: 13161
Credit: 1,160,866,277
RAC: 1,873
United States
Message 1927018 - Posted: 29 Mar 2018, 3:37:37 UTC - in response to Message 1927014.  

Also set Vsoc to Manual at 1.05V. Auto always sets it to 1.10V and that is too much for the past 3 or 4 BIOS releases. The cpu is much more stable at less Vsoc voltage. The Ryzen RAM calculator recommends even lower voltage at 1.025V for most of the Hynix and Samsung memory kits at any XMP level less than 3200. The higher the Vsoc, the less stable for common memory kits because the lower voltage INCREASES the signal to noise ratio in the IMC control circuitry which is beneficial. The only reason to run 1.10 or higher Vsoc is if you are shooting for 3466 or higher
Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)
ID: 1927018 · Report as offensive
Profile Karsten Vinding
Volunteer tester

Send message
Joined: 18 May 99
Posts: 239
Credit: 25,201,931
RAC: 11
Denmark
Message 1927035 - Posted: 29 Mar 2018, 7:02:19 UTC - in response to Message 1927018.  

Thanks for that info :)

I have reduced Vsoc to 1.05. Anything that helps with stability, and probably reduces power usage, is good.

I just downloaded the latest DRAM calculator. It has been much improved since last time I tried using it. Allthough it still recommends 53,3 Ohm for my ram.
ID: 1927035 · Report as offensive
Profile Keith Myers Special Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 29 Apr 01
Posts: 13161
Credit: 1,160,866,277
RAC: 1,873
United States
Message 1927095 - Posted: 29 Mar 2018, 14:40:09 UTC - in response to Message 1927035.  

The new information about 48 ohms has come to light in that thread from a couple of long-term testers with their testing of 3805. Sort of a mixed bag response to the new calculator. Some saying that it allowed 3200 where never before possible and others swearing the older versions were better for finding stability at > 3200. Some even have reverted way back to 1001 BIOS.

You just have to try everything and see what is stable on your hardware. The new system has been stable for a day so I will try to tighten to CL14 again.
Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)
ID: 1927095 · Report as offensive
Profile Karsten Vinding
Volunteer tester

Send message
Joined: 18 May 99
Posts: 239
Credit: 25,201,931
RAC: 11
Denmark
Message 1927104 - Posted: 29 Mar 2018, 15:09:05 UTC - in response to Message 1927095.  

I cant say for sure yet, but the system has been running for ~ 12 hrs since I changed the resistance to 48 Ohms, I rebooted the system ~ 8 hrs ago to change the Vsoc, but otherwise it has been stable.

The change to VSOC reduced my core temps with ~ 3 degrees C. More than I expected...

I'm very hopefull that these changes could bring stability, but in reality my dream is for AMD to bring out a working AGESA that fixes these problems.

I suspect their focus right now is the upcoming 2x00 series, and of course fixing the security "holes" reported by the stock market speculating CTS-labs.
ID: 1927104 · Report as offensive
Profile Karsten Vinding
Volunteer tester

Send message
Joined: 18 May 99
Posts: 239
Credit: 25,201,931
RAC: 11
Denmark
Message 1927144 - Posted: 29 Mar 2018, 20:15:47 UTC - in response to Message 1927104.  

Damn, the system just bluescreened without any warning while I was typing on the keyboard.

The error was something about a system exception, so seemingly not a memory error.

I have turned the vcore to the CPU up a notch, perhaps that can bring the last bit of stability.
ID: 1927144 · Report as offensive
Profile Keith Myers Special Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 29 Apr 01
Posts: 13161
Credit: 1,160,866,277
RAC: 1,873
United States
Message 1927161 - Posted: 29 Mar 2018, 21:22:03 UTC - in response to Message 1927144.  

In my experience a BSOD with System Exception IS a memory problem. Insufficient Vcore always exhibited a black screen where the system doesn't respond to keyboard or mouse and only a reset reboots the system. It also NEVER writes a kernel dump so tools like BlueScreenView are useless. Hope the bump in Vcore helps you out. If it doesn't, I would bump Vdimm another 25mV.
Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)
ID: 1927161 · Report as offensive
Profile Karsten Vinding
Volunteer tester

Send message
Joined: 18 May 99
Posts: 239
Credit: 25,201,931
RAC: 11
Denmark
Message 1927251 - Posted: 30 Mar 2018, 4:02:41 UTC - in response to Message 1927161.  

Well raising VCore didn't help, this time it black screened....

Its allways easy for me to spot, as fans go to max speed, and the computer gets rather noisy. And most of the time I cant simply reset it, I have to toggle the power switch on the PSU.

Something is obviously still not OK...
On 3803 I never saw a black screen on DDR 2400 speeds. I suspect I could end up there on 3805 too.

I must experiment with mem speed to see what I can reliably reach, but will also turn down my CPU OC, to rule out instability due to that.

This is frustrating, the system was very solid on 3401, so having to deal with these things now is SO irritating.
ID: 1927251 · Report as offensive
Profile Keith Myers Special Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 29 Apr 01
Posts: 13161
Credit: 1,160,866,277
RAC: 1,873
United States
Message 1927273 - Posted: 30 Mar 2018, 5:58:35 UTC - in response to Message 1927251.  

It is frustrating . . . . and time consuming. Change one variable and test for a couple of days. Change another variable. I decided to try upping the clock speed since I was stable at the lower clock speed. Still at 3200C16. Only try one thing at a time. I want to get back to my previous stable 3.95Ghz. At 3.9Ghz now. If I can get back to 3.95, then I will try to find stability at CL14, or drop back to 3.9.
Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)
ID: 1927273 · Report as offensive
Profile Karsten Vinding
Volunteer tester

Send message
Joined: 18 May 99
Posts: 239
Credit: 25,201,931
RAC: 11
Denmark
Message 1927505 - Posted: 31 Mar 2018, 14:13:04 UTC - in response to Message 1927273.  

My system has now been running 34hrs without a crash.

This with memory timings at DOCP3200 settings, but with mem clock reduced to 3133 Mhz.

This is very promising, and I can live with the small speed reduction on the RAM, if this proves to be reliable.
ID: 1927505 · Report as offensive
Profile Keith Myers Special Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 29 Apr 01
Posts: 13161
Credit: 1,160,866,277
RAC: 1,873
United States
Message 1927521 - Posted: 31 Mar 2018, 16:52:38 UTC - in response to Message 1927505.  

That's very encouraging. We know that memory speed affects the infinity fabric speed and thus the processor. Why we want it as fast as possible. But if a slower speed gets you stability, you sacrifice that to keep the cruncher running and reporting valid work.
Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)
ID: 1927521 · Report as offensive
Profile Karsten Vinding
Volunteer tester

Send message
Joined: 18 May 99
Posts: 239
Credit: 25,201,931
RAC: 11
Denmark
Message 1930919 - Posted: 19 Apr 2018, 17:48:49 UTC - in response to Message 1927521.  

Have you tried the latest 4009 BIOS'es, or read anything about them?

I'm downloading at the moment, will report if I see improvements.
ID: 1930919 · Report as offensive
Profile Karsten Vinding
Volunteer tester

Send message
Joined: 18 May 99
Posts: 239
Credit: 25,201,931
RAC: 11
Denmark
Message 1930925 - Posted: 19 Apr 2018, 18:42:05 UTC - in response to Message 1930919.  

Well, that test didn't last long.

I installed the BIOS, went into BIOS, and set the same settings as before, with the exception of letting the RAM run at its specified 3200MHz.

Booted windows and started using it. The computer crashed with a blue screen within 10 minutes....

I have rebooted now, with 3133MHz RAM, where it was stable on the 3805 Bios.

I hope it still is.....
ID: 1930925 · Report as offensive
Previous · 1 · 2 · 3 · 4 · 5 · Next

Message boards : Number crunching : (0xC0000005) STATUS_ACCESS_VIOLATION any idea what caused it?? Or what it exactly is describing?? Internet searches find nothing.


 
©2024 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.