Random BSOD ATTEMPTED_WRITE_TO_READONLY_MEMORY

[bsfinkel]

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

 

[x BlueRobot]

[COLOR="Red"]BugCheck BE[/COLOR], {[COLOR="SeaGreen"]c0297108[/COLOR], 230d3025, b9441c44, b}

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

0: kd> [COLOR="SeaGreen"]!pte c0297108[/COLOR]
                    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.

b9441c44 -- ([COLOR="SeaGreen"].trap 0xffffffffb9441c44[/COLOR])
ErrCode = [COLOR="Red"]00000003[/COLOR]
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
[COLOR="Blue"]nt!MmAccessFault+0x177e[/COLOR]:
82edfef5 f00fc70e        [COLOR="Red"]lock[/COLOR] 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:

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

0: kd> [COLOR="SeaGreen"]kv[/COLOR]
 # ChildEBP RetAddr  Args to Child              
00 b9441c2c 82e91aa8 00000001 [COLOR="Red"]c0297108[/COLOR] 00000000 nt!MmAccessFault+0x104
01 b9441c2c 82edfef5 00000001 [COLOR="Red"]c0297108[/COLOR] 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:

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.

• http://www.sevenforums.com/performa...registry-cleaner-tests-why-not-use-one-2.html

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 - http://www.sevenforums.com/bsod-help-support/299128-bsod-bad_pool_header-19-a.html#post2481656

Did Comodo provide a patch in the end? http://www.sevenforums.com/bsod-help-support/299128-bsod-bad_pool_header-19-a-2.html#post2484543

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

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?

Start Menu\Programs\Java

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

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:

• http://www.sevenforums.com/tutorial...ation-conflicts-performing-clean-startup.html
• http://www.sevenforums.com/tutorials/1401-startup-programs-change.html

 

[bsfinkel]

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

 

[x BlueRobot]

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.

 

[bsfinkel]

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

 

[x BlueRobot]

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.

 

[bsfinkel]

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

 

[x BlueRobot]

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

 

[bsfinkel]

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

 

[x BlueRobot]

What about the Advanced Systemcare 6?

Any other crashes recently?

 

[bsfinkel]

I have not uninstalled ASC6 (except to replace it with the newer 7.0.5). I have not had a BSOD that I can attribute to anything ASC did.

As for recent BSODs (after the READONLY_MEMORY BSOD that is the subject of this problem report:

11/03/2013 00:52 BSOD: (74) MEMORY MANAGEMENT (1a) 41289 third occurrence
11/04/2013 01:13 BSOD: (75) BAD_POOL_CALLER (c2) 7 second occurrence
11/06/2013 08:55 BSOD: (76) NTFS_FILE_SYSTEM (24) 001904fb third occurrence
11/08/2013 11:33 BSOD: (77) DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1) storport.sys first occurrence

These are all different, and I see no pattern. That is why I call my BSODs "seemingly random".
--Barry Finkel

 

[x BlueRobot]

Could you please upload the resulting dump files?

 

[bsfinkel]

I have uploaded the current output of SF diagnostic tool. And as an extra "bonus" there is a BSOD from this morning:

11/10/2013 05:41 BSOD: (78) BAD_POOL_HEADER (19) i20 mage name=win32k.sys

That is my tenth BAD_POOL_HEADER (19) Arg1=00000020 BSOD. I am not sure that they are all caused by the same driver/program. This was the first one with this image name.
--Barry Finkel

 

[x BlueRobot]

[COLOR=Red]BugCheck 19[/COLOR], {[COLOR=Blue]20[/COLOR], fe437160, fe4371a8, 4a090001}

Probably caused by : win32k.sys ( win32k!WMsg_midl_user_free+10 )

1: kd> [COLOR=SeaGreen]dt nt!_POOL_HEADER fe437160[/COLOR]
   +0x000 PreviousSize     : 0y000000001 (0x1)
   +0x000 PoolIndex        : 0y0000000 (0)
   +0x002 BlockSize        : [COLOR=Red]0y000001001 (0x9)[/COLOR]
   +0x002 PoolType         : 0y0100101 (0x25)
   +0x000 Ulong1           : 0x4a090001
   +0x004 PoolTag          : 0x6c6d7355
   +0x004 AllocatorBackTraceIndex : 0x7355
   +0x006 PoolTagHash      : 0x6c6d

1: kd> [COLOR=SeaGreen]dt nt!_POOL_HEADER fe4371a8[/COLOR]
   +0x000 PreviousSize     : [COLOR=Red]0y000000000 (0)[/COLOR]
   +0x000 PoolIndex        : 0y0000000 (0)
   +0x002 BlockSize        : 0y001001100 (0x4c)
   +0x002 PoolType         : 0y0100011 (0x23)
   +0x000 Ulong1           : 0x464c0000
   +0x004 PoolTag          : 0x35616c47
   +0x004 AllocatorBackTraceIndex : 0x6c47
   +0x006 PoolTagHash      : 0x3561

We can see that the _POOL_HEADER data structure has become corrupt, the Pool Header of next entry's PreviousSize field doesn't match the BlockSize field of the pool entry which which was being checked within the pool page.

This is pretty much caused by drivers.

There's still a few programs and drivers on your system, which were causing problems in your previous thread.

 

[bsfinkel]

I am not sure what you mean. "There's still a few programs and drivers on your system, which were causing problems in your previous thread." The drivers that have definitely been implicated on previous BSODs have been removed or replaced. These are cbufs.sys, wrkrn,sys, and the nVIDIA graphics driver. Other BSODs are probably caused by bad drivers, but we have not implicated a specific driver in any of the unresolved BSODs. One of my brothers is "convinced" that my problems are due to the VIA IDE card in my computer. He says that because I changed motherboards last May, and, besides the video card, that is the only other card in my machine. I do not agree with him.

Here are the non-MS drivers as seen by verifier:

amdxata.sys - AMD Storage Filter Driver
bdisk.sys - COMODO
cbreparse.sys - COMODO Cloud
cbvd.sys - COMODO
vdbus.sys - COMODO BackUp Virtual Disk Bus Driver
dump_atapi.sys - ?? IDE Port Driver
dump_dumpata.sys - ?? Parallel ATA
dump_dumpfve.sys - ?? Full Volume Encryption Crashdump Hibernate Filter
e1e6232.sys - Intel(R) PRO/1000 Adapter NDIS 6 deserialized driver
eubakup.sys - EaseUS-Backup
eubkmon.sys - EaseUS-Backup
ndis.sys - Microsoft
vsmraid.sys - VIA RAID Driver

The vsmraid.sys driver is for my VIA IDE card, but I do not use the RAID feature. The VIA web site says that the IDE drivers in use for Windows 7 is the MS-supplied driver. I have just renamed the four COMODO drivers, as I no longer use COMODO. I will reboot to see if there are problems with the renames. The other drivers seem to be needed on my system. And I don't agree with the statement - It is not necessary to test MS drivers; they do not cause problems.
It could be a MS driver that has caused one or more of my BSODs. I did a Google search last week on one of my BSODs, and I saw a hotfix for stream.sys (kb2661796). I downloaded the hotfix, and when I run it it asks me for a directory into which to unzip. Then it completes immediately. There is nothing new in the unzip directory, nor has stream.sys been updated. I have rebooted after the "install". I have no idea what is happening when I install that hotfix. I have no idea how many driver hotfixes have been written by MS for Windows 7 Professional, but have not been released on patch Tuesdays because they are not pervasive problems. This one hotfix was from early 2012.
--Barry Finkel

 

[bsfinkel]

One quick update - the reboot after the rename of the four COMODO files had two problems. First, a "BAD_POOL_HEADER (19)" BSOD during shutdown (I have experienced this before), then a repeasted "(7b)" BSOD during reboot. After multiple reboots into XP to un-rename and re-rename, I determined that bdisk.sys is need to boot, and I have to determine why this COMODO driver is needed. None of the four COMODO drivers is currently in the verifier list. The other three COMODO drivers have been successfully renamed, and can't be loaded.
--Barry Finkel

 

[x BlueRobot]

I don't understand, why you won't simply remove the Comodo program if your not using it?

 

[bsfinkel]

It is true that I no longer use Comodo Backup to make backups of my disks. But I do have prior backups, and there may be a time in the future when I may need to restore a file from one of those backups.
--Barry Finkel

 

[x BlueRobot]

Just download a better backup program, and then create new backups.

 

[bsfinkel]

I HAVE installed a new backup program, and I am using it. But, if I have to restore a file back from last July, for example, that file will NOT be on a backup tape created today or last week. That is why I have not uninstalled Comodo Backup. I have renamed the driver file that caused at least one of my BSODs, so that driver file will not be loaded and will not cause another BSOD. If the offending program were any other program, I would have no qualms about uninstalling it. My main concern right now is to determine the causes of my seemingly random BSODs. Besides the one caused by cbufs.sys and the ones caused by nVIDIA graphics driver timeouts, I have nor determined a definitive cause for any of my other BSODs. I do not know enough about the internals of Windows 7 nor all of the various windbg commands to be able, on my own, to look at a dump (full or mini) and pinpoint the offending program.
--Barry Finkel