Jump to content


 


Register a free account to unlock additional features at BleepingComputer.com
Welcome to BleepingComputer, a free community where people like yourself come together to discuss and learn how to use their computers. Using the site is easy and fun. As a guest, you can browse and view the various discussions in the forums, but can not create a new topic or reply to an existing one unless you are logged in. Other benefits of registering an account are subscribing to topics and forums, creating a blog, and having no ads shown anywhere on the site.


Click here to Register a free account now! or read our Welcome Guide to learn how to use this site.

Photo

Bsod In Regedit Search And Anti-spyware Scans


  • Please log in to reply
No replies to this topic

#1 bart_central

bart_central

  • Members
  • 12 posts
  • OFFLINE
  •  
  • Local time:12:03 AM

Posted 15 November 2007 - 03:47 PM

Hello,

This is a continuation of an HJT topic that can be found at...

http://www.bleepingcomputer.com/forums/ind...view=getnewpost

It's a long series of posts. To summarize, my system had been infected and was subsequently cleaned - but there appears to still be a problem with my registry. The people over on the HJT forum believe the system is now clean and recommended I post here in order to address the registry issue.

First, details about my system...

SYSTEM: Gateway desktop (around 5 years old)
PROCESSOR: P4 2.4Ghz
MEMORY: 2Gb
HARD DRIVES: 2 (non SCSI)
OS: Windows XP Professional (with autoupdate enabled)
BROWSER: IE7

I have a twin to the above system that was not infected and does not have registry problems (it has a different display card and there are differences in the installed software).


The problem...

Searches in regedit for things that are already on screen (i.e. does not have to go very far down to find whatever you're searching for) or just beyond what's on screen work without any problems. Searches for stuff that is considerably further down or for things that are not in the registry at all will crash the system - resulting in a BSOD. The same thing applies to a number of the anti-spyware apps that I have tried to use and which do a detailed scan of the registry.

In all other cases that I can tell, the system works just find. In other words, it's not like my system isn't booting up or that running any other applications causes the system to crash. To date, scanning through the registry is the only thing that causes the BSOD.


Attempts to investigate/fix the problem...

Early on, I tried swapping memory between the problem system and its twin to see if the behavior changed. It did not - making it unlikely that this is a memory problem.

The following steps were recommended back when I was dealing with this via the HJT thread. Per the 10/22 entry, I installed the Free Window Registry Repair (Free edition) and ran it several times. It initially found a large number of errors (1,318). Each time, the number of errors would drop - leveling off at around 11. I understand that some of the reported errors can be false positives and I suspect that that is the case here. Rebooting sets the count back up to around 87 errors (i.e. reboot and then run the scan again). In any case, the scan/fix passes appear to have had no effect on the registry problem. Curiously, this app does NOT cause a BSOD.

Per the 10/24 entry, I installed the Microsoft Debugging Tools and ran them as instructed. I also ran the Disk Check utility. Here is a cut/paste of the results (from that thread)...

------------------------------------------------------------------Begin Paste from HJT Thread---------------------------------------------------------------------
Next, I installed the debugging tool and ran it. Here is the information it provided...
------------------------------------------------------------
Microsoft Windows Debugger Version 6.8.0004.0 X86
Copyright Microsoft Corporation. All rights reserved.


Loading Dump File [C:\WINNT\Minidump\Mini102407-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 2) UP Free x86 compatible
Product: WinNt
Built by: 2600.xpsp_sp2_gdr.070227-2254
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055a620
Debug session time: Wed Oct 24 00:47:53.593 2007 (GMT-7)
System Uptime: 0 days 0:09:18.171
Loading Kernel Symbols
................................................................................
..............................................................................
Loading User Symbols
Loading unloaded module list
...............
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 51, {4, 1, e2dbb680, 618}



Probably caused by : ntoskrnl.exe ( nt!CmpAssignSecurityToKcb+3f )

Followup: MachineOwner
---------

kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

REGISTRY_ERROR (51)
Something has gone badly wrong with the registry. If a kernel debugger
is available, get a stack trace. It can also indicate that the registry got
an I/O error while trying to read one of its files, so it can be caused by
hardware problems or filesystem corruption.
It may occur due to a failure in a refresh operation, which is used only
in by the security system, and then only when resource limits are encountered.
Arguments:
Arg1: 00000004, (reserved)
Arg2: 00000001, (reserved)
Arg3: e2dbb680, depends on where Windows bugchecked, may be pointer to hive
Arg4: 00000618, depends on where Windows bugchecked, may be return code of
HvCheckHive if the hive is corrupt.

Debugging Details:
------------------




CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x51

LAST_CONTROL_TRANSFER: from 8060c2a6 to 8053354e

STACK_TEXT:
af8fa90c 8060c2a6 00000051 00000004 00000001 nt!KeBugCheckEx+0x1b
af8fa930 8058d544 00000008 00000618 dab07e1c nt!CmpAssignSecurityToKcb+0x3f
af8fa958 8058b6c7 e1035b60 00406e18 dab07e1c nt!CmpCreateKeyControlBlock+0x1b5
af8fa9a8 805679a0 e1035b60 00406e18 dab07e1c nt!CmpDoOpen+0xf4
af8faba0 805676b5 00406e18 00406e18 88b47b70 nt!CmpParseKey+0x558
af8fac28 8056749a 000000cc af8fac68 00000040 nt!ObpLookupObjectName+0x119
af8fac7c 80567dfd 00000000 8a738650 00000001 nt!ObOpenObjectByName+0xeb
af8fad50 804de7ec 0007f478 00000009 0007f3d8 nt!NtOpenKey+0x1af
af8fad50 7c90eb94 0007f478 00000009 0007f3d8 nt!KiFastCallEntry+0xf8
WARNING: Frame IP not in any known module. Following frames may be wrong.
0007f418 00000000 00000000 00000000 00000000 0x7c90eb94


STACK_COMMAND: kb

FOLLOWUP_IP:
nt!CmpAssignSecurityToKcb+3f
8060c2a6 ff33 push dword ptr [ebx]

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: nt!CmpAssignSecurityToKcb+3f

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntoskrnl.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 45e54711

FAILURE_BUCKET_ID: 0x51_nt!CmpAssignSecurityToKcb+3f

BUCKET_ID: 0x51_nt!CmpAssignSecurityToKcb+3f

Followup: MachineOwner
---------

------------------------------------------------------------------------------

When I googled ntoskrnl.exe, the entries seemed to focus on corrupted or missing versions of this file. In my case, it seems as if something that ntoskrnl.exe is using is what is actually bad.

In the very recent past (near the top of this thread), I have swapped memory with a twin of my system (it was one of the first things I thought of) and it did not have any affect on the REGISTRY_ERROR problem - so I don't think the problem is with the system's memory.

My next step was to run the Windows XP Disk Check Utility (I'm running XP, not Vista).
The process was the same as you described for Vista. I checked neither option ("Automatically fix file system errors" and "Scan for and attempt recovery of bad sectors") before starting the check.

The check moved along until it got to the second tick in stage 2. It then sat there, seemingly frozen, for several minutes before producing a dialog that read "Windows was unable to complete the disk check". When I dismissed the dialog, the diskcheck screen went away as well.

I then tried the disk check and checked both options this time. The app came back with the "cannot be performed right now" dialog (as expected) and I scheduled it for the next reboot.

Upon rebooting the system, the check began. Stage 1 (file verification) completed and Stage 2 (verifying indexes) got as far as 6% before grinding to a halt. The machine sat that way for some time. The next time I checked on it, it had apparently started up again and completed stage 2 as well as stage 3 (security description verification followed by Usn Journal verification) and was moving very slowly through stage 4 (verifying file data). Eventually it completed stage 4 and began stage 5 (verifying free space). Upon completing this stage, it reported some information but restarted before I could read it all. It appears to have made some corrections and found some free space that had been marked as allocated. I didn't catch the rest.

Upon rebooting, I tried the regedit search again and still got the same BSOD.

So with runnig the above apps, it looks like the hard drive and file structure seems good, and the consistency of the failures (along with my having swapped all of the system's memory with that of a duplicate system) seems to me to make bad memory an unlikely candidate. It all seems to come back to it being a problem with the registry (?!?)
------------------------------------------------------------------End Paste from HJT Thread---------------------------------------------------------------------

One additional note: each time I reproduce this error, the error number is always the same and of the four argument values that are reported, arg 3 (value "e2dbb680" in the above example) is the only one that changes from one BSOD to the next. In other words, it looks like the nature of the failure is pretty consistent.


Please let me know if you need any additional information. Any help you could provide would be much appreciated!

-- bart_central

Edited by bart_central, 15 November 2007 - 03:53 PM.


BC AdBot (Login to Remove)

 





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users