Random BSOD ATTEMPTED_WRITE_TO_READONLY_MEMORY

I had another seemingly random BSOD - ATTEMPTED_WRITE_TO_READONLY_MEMORY (be). The windbg output says that the offending driver name is saved in KiBugCheckDriver. I do not know enough about windbg to be able to find the driver name.

I have made a summary of all of the 73 BSODs I have experienced since I installed a new motherboard last May 23, and this is the first BSOD with this symptom string.

Note that I am still running verifier.exe on most non-MS drivers, per a previous sevemforums problem report.

--Barry Finkel

Code:

BugCheck BE, {c0297108, 230d3025, b9441c44, b}

Probably caused by : ntkrpamp.exe ( nt!KiTrap0E+dc )

Code:

0: kd> !pte c0297108
                    VA 52e21000
PDE at C06014B8            PTE at C0297108
Unable to get PDE C06014B8

Your not going to gather much information from this bugcheck with a Minidump, unless your lucky or have a Kernel Memory dump.

Code:

b9441c44 -- (.trap 0xffffffffb9441c44)
ErrCode = 00000003
eax=ffffffff ebx=ffffffff ecx=ffffffff edx=ffffffff esi=c0297108 edi=445ed025
eip=82edfef5 esp=b9441cb8 ebp=b9441d1c iopl=0         nv up ei ng nz na pe nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00210286
nt!MmAccessFault+0x177e:
82edfef5 f00fc70e        lock cmpxchg8b qword ptr [esi] ds:0023:c0297108=25d05e4400000080

An interesting thing here, is that the trap frame was created as a result of a breakpoint, which shouldn't be found in commercial code, since it's used for debugging purposes to allow the developer to find any bugs in their code at a certain point.

The Assembly lock is usually used for some form of synchronization, which is evident within the raw stack:

Code:

0xb9441c30 : 0x82e91aa8 : nt!KiTrap0E+0xdc
0xb9441c44 : 0xb9441d1c :  Trap @ b9441c44
0xb9441c54 : 0x82ecbf9d : nt!KeAccumulateTicks+0xc8
0xb9441c8c : 0x82ecb763 : nt!KeUpdateRunTime+0x145
0xb9441cc8 : 0x82f7bc00 : nt!KiInitialPCR
0xb9441cf0 : 0x82e1f924 : hal!HalpDispatchSoftwareInterrupt+0x5e
0xb9441d04 : 0x82e1fb29 : hal!HalpCheckForSoftwareInterrupt+0x83
0xb9441d20 : 0x82e91aa8 : nt!KiTrap0E+0xdc

Code:

0: kd> kv
 # ChildEBP RetAddr  Args to Child              
00 b9441c2c 82e91aa8 00000001 c0297108 00000000 nt!MmAccessFault+0x104
01 b9441c2c 82edfef5 00000001 c0297108 00000000 nt!KiTrap0E+0xdc (FPO: [0,0] TrapFrame @ b9441c44)
02 b9441d1c 82e91aa8 00000000 52e21bf8 00000001 nt!MmAccessFault+0x177e
03 b9441d1c 523e7fdd 00000000 52e21bf8 00000001 nt!KiTrap0E+0xdc (FPO: [0,0] TrapFrame @ b9441d34)
WARNING: Frame IP not in any known module. Following frames may be wrong.
04 0018b6cc 00000000 00000000 00000000 00000000 0x523e7fdd

Notice the virtual address being passed to a two function calls in the stack?

What Driver Verifier settings have enabled?

Remove:

Code:

Start Menu\Programs\Advanced SystemCare 6

Windows 7 doesn't require any programs which make changes to the operating system and registry, these programs tend to cause problems by modifying and deleting files.

• Registry Cleaner Tests - Why NOT To Use One!

Windows is a closed source system. Developers of registry cleaners do not have the core code of Windows 7 and are not working on definitive information, but rather they are going on past knowledge and experience. Automatic cleaners will usually have to do some guesswork.

Modifying registry keys incorrectly can cause Windows instability, or make Windows unbootable. No registry cleaner is completely safe and the potential is ever present to cause more problems than they claim to fix.

Registry cleaners cannot distinguish between good and bad. If you run a registry cleaner, it will delete all those keys which are obsolete and sitting idle; but in reality, those keys may well be needed by some programs or windows at a later time.

Windows 7 is much more efficient at managing the registry than previous Windows versions. If you run any other registry cleaner and do not know precisely what you are doing, you will have problems down the road. There are no gains to be had from using a registry cleaner and the risk is great.

I have given this same advice in your previous thread - Bsod bad_pool_header (19)

Did Comodo provide a patch in the end? Bsod bad_pool_header (19)

You seem to have their software installed, which I'm not sure if that is still a problem or not:

Code:

Start Menu\Programs\COMODO
Start Menu\Programs\COMODO\COMODO BackUp
Start Menu\Programs\COMODO\COMODO Cloud

Do you have the latest version of Java installed?

Code:

Start Menu\Programs\Java

I would be careful with Webroot, I've seen that program directly cause BSODs with a few other cases:

Code:

Start Menu\Programs\Webroot SecureAnywhere
Start Menu\Programs\Webroot SecureAnywhere\Tools

You also seem to be running two anti-virus programs, which can cause serve conflicts, my recommendation would be to remove Webroot and stay with MSE.

Reduce the number of programs at startup, to avoid any driver or program conflicts:

• Troubleshoot Application Conflicts by Performing a Clean Startup
• Startup Programs - Change

Here are replies to your individual items:

-----
>Your not going to gather much information from this bugcheck with a Minidump, unless your lucky or have a Kernel Memory dump.

I have a full dump for this and most other BSODs. The memory dump file for this BSOD is 402.5Mb. Do you want it, or do you want to send me the windbg commands to run? Note that after each BSOD I immediately rename the memory.dmp file to preserve it.

-----

> What Driver Verifier settings have enabled?

C:\Windows\System32\drivers>verifier /querysettings
Special pool: Enabled
Pool tracking: Enabled
Force IRQL checking: Enabled
I/O verification: Enabled
Deadlock detection: Enabled
DMA checking: Enabled
Security checks: Enabled
Force pending I/O requests: Enabled
Low resources simulation: Disabled
IRP Logging: Enabled
Miscellaneous checks: Enabled

Verified drivers:

vsmraid.sys
amdxata.sys
cbreparse.sys
eubkmon.sys
eubakup.sys
bdisk.sys
cbvd.sys
e1e6232.sys
ndis.sys
vdbus.sys
dump_dumpata.sys
dump_atapi.sys
dump_dumpfve.sys

C:\Windows\System32\drivers>

I have not disabled verifier, as it seems not to cause performance problems with my normal use of Windows 7.

-----

> Start Menu\Programs\Advanced SystemCare 6

I realize that SevenForums does not like ASC because it changes the registry. If I ever get a dump that points to ASC as the cuyprit, then I will uninstall ASC or contact IObit. If the registry is a closed system, then NO PROGRAM that is not MS-written should update the registry.

The only problem I have had with IObit is their SmartDefrag. Their driver, SmartDefragDriver.sys, uses an identifier that is not an alpha-numeric string. This does not cause problems when I run SmartDefrag, but it causes an IMMEDIATE BSOD with verifier, and there is no dump produced because the problem occurs too early in the boot process for dumps to be enabled. I have an open trouble ticket with IObit, and I know not to include SmartDefragDriver.sys in the verifier driver list.

-----

> Did Comodo provide a patch in the end?

No. The Comodo backup program I was running was free-ware, and from the Comodo forums it appears that Comodo does not respond to posts about their non-pay software. So, I renamed cbufs.exe, and I installed and use a different backup program. I do get a message a boot time (which I see in safe mode) that cbufs.sys cannot be loaded. I had posted another question on the Comodo forums earlier, and there had been no response. None of those three COMODO tasks is running on my system.

-----

> Do you have the latest version of Java installed?

I have Java 7 U45 installed. (build 1.7.0_45-b18)

-----

> I would be careful with Webroot, I've seen that program directly cause BSODs with a few other cases:

I had a problem with wkrn.sys, and WebRoot analyzed the BSOD and gave me new code. When I change the verifier settings to include the updated wkrrn.sys, the boot hangs. Webroot says that they do not use verifier, and they are not concerned about this. I have had no further BSODs that point to wrkrn.sys, so I assume that the new WebRoot code is working correctly. I know not to include wrkrn.sys in the verifier settings.

-----

Note that there are other unexplained BSODs, including a second "DRIVER_VERIFIER_DETECTED_VIOLATION (c4)" fileinfo.sys that occurred last night at 18:11.

--Barry Finkel

If your using a different backup program, you may as well remove the program completely. ASC 6 won't cause any BSOD's directly since it's a User-Mode program, and I think you may have got a little confused about the closed system part.

The closed system statement refers to Windows source code and not the registry, and registry cleaners do not update the registry they tend to remove registry entries which are dormant. They provide no benefits at all. Registry cleaners were only popular when computers had very little RAM or hard disk space; Microsoft even released their own registry cleaner with Windows at one point. Most forums will not recommend the use of a registry cleaner.

IOBit is another program which just causes problems.

You have also included a couple of Windows drivers in the Driver Verifier settings, for example ndis.sys.

Do you know what Webroot use? Driver Verifier was directly created for driver developers.

In regards, to the Minidump situation, you could try using the !pte extension on the the first parameter, and then posting the information over using the code tags which is the # symbol.

A quick reply.

1) I must have included ndis.sys in verifier by mistake. I tried to include only the non-MS drivers. Including this one by mistake is not causing problems.

2) I have no idea what WebRoot uses to test drivers. They said that they do not use verifier, and I really am not interested in what they use. I now know not to include their driver in verifier.

3) From the full dump:

0: kd> !pte c0297108
VA 52e21000
PDE at C06014B8 PTE at C0297108
contains 00000000230D3025 contains 80000000445ED025
pfn 230d3 ----A--UREV pfn 445ed ----A--UR-V

Is this that you wanted? What else you need from the dump?
--Barry Finkel

That's fine thanks :)

The !pte is most useful extension I know of for that bugcheck, just need to check the protection status bits.

We can see that the page has been Accessed since the last clearance of this bit (A), therefore a device driver did write to this page. The V or Valid indicates that the page does map to a physical page in memory. The U is reserved (for Windows use?), but indicates that the page is writiable for multiprocessor systems. The most important aspect, is that the W bit is clear, which should indicate the page is read-only.

A quick reply to something you wrote previously. I have not uninstalled Comodo Backup because I have backups, and I might need to restore something from those backups sometime in the future. Is there anything else you need from the full dump?
--Barry Finkel

No, that is about it thanks. Which programs or drivers have you removed?

I renamed cbufs.sys, and I installed a new wrkrn.sys from WebRoot. Other BSOD dumps are probably due to bad drivers, but I cannot tell from the dumps what driver caused each dump. The only program I removed was IObit Malware Fighter.
--Barry Finkel

What about the Advanced Systemcare 6?

Any other crashes recently?