Scecli and ESENT errors event log (long)



Hi all,

I was wondering if any of you can help me with the following problem
which has been driving me nuts for the past few months and none of the
solutions found on the internet work (for more than two days anyway).

First off, standalone windows 2000 computer, SP4 with all updates, US
edition. I'm logged on not as administrator but as user with
administrative privileges.

I'm getting repeated instances of the following errors in my event

Event ID 439
Services (248): Unable to write a shadowed header for file

Event ID 427
Services (248): The database engine could not access the file called

Event ID 1202
Security policies are propagated with warning (0x4b8): an extended
error has occurred.

In addition, I cannot access the local security database (access

Once the errors appear in the event log, I check the database for
integrity with the command:
esentutl /g %SystemRoot%\security\database\secedit.sdb

Output: the database is inconsistent.There may be uncommitted
logfiles. Operation terminated with error -1206
(JET_errDatabaseCorrupted, Non database file or corrupted db) after
1.391 seconds

I then remove all logs from c:\winnt\security as
well as c:\winnt\security\logs (after closing the handle on
scepol.log). I then recreate the local security database through the
MMC snap in procedure as outlined in KB 278316.

Lo and behold, integrity checks out OK with esentutl, I can access the
local security policy again and error are gone from the event log. For
about two days

The only policy I implement is to not have my password expire after 42
days (set to 0 days).

I also applied the following tweaks (probably irrelevant):
- disabled administrative shares
- disallowed my account full access to the regedit key in the registry
to prevent Windows from displaying the most recently viewed key

I checked security rights on C, WINNT as well as the Security folder
and they are identical to the ones on my machine at work. I never
messed with access rights apart from disabling administrative shares
through a registry key (problem also occurs with administrative shares
enabled). Admin account was not renamed either (besides, that'ss a
server policy).

After browsing the Internet for hours on end I don't know what to do
Do you guys have any ideas what's going on?



David Everett [MSFT]

Hi Yvonne,

I found a similar case where they followed 278316 and the problem would
return after a couple of weeks. This customer had Write-through cache
disabled but the IDE controller they were on did not honor it. Do you have
Write-back cache disabled on your the controller? If your Drives support
write-back cache you may have to turn this off with a jumper on each disk,
even if you have turned it off on the controller.

324805 HOW TO: Manually Turn Disk Write Caching On or Off

259716 HOW TO: Manually Enable/Disable Disk Write Caching

In another case the Anti-virus scanning was causing the corruption. If you
restore the database by following 278316 and configure the Anti-virus not to
scan the database folder where secedit.sdb is located does the problem go
away? If it does you should contact the vendor of the Antivirus application
for a fix so you can continue to scan the entire machine.

What Operating System is the server running and what service pack? Any
hotfixes installed?

What is the exact location of the key in the registry where you are locking
down permissions to yourself? What are you setting security to on this key?

What happens if you restore the security database like it says in 278316 and
you don't alter anything in the registry, does the problem return?

Derek Melber [MVP]

Two things come to mind:

1) if you turn off administrative shares on a DC... this might mess up the
SYSVOL and Netlogon shares. Might want to check those out.
2) If you are updating GPOs with a client computer, there could be some
strange behavior with permissions or versions of the files that are on the
client computer vs the DC. Might want to make sure all ADM templates are
synched before you do any editing of the GPOs from the client computer.


Hello David and Derek, thank you for responding.

First of all, my machine is a standalone Windows computer, not
connected with a server or DC. SP4 is installed as are all the latest

David, you asked for the registry keys I change:

- disable administrative shares:
HK_L_M\System\CurrentControlSet\Services\LanmanServer\Parameters (add
AutoShareWks with Reg)DWord value of 0);
- disable regedit history:
Use regedt32 to change permissions to this key:
(changed access by my account to Read-Only).

I'm using Nod32 as my AV software. The idea had occurred to me that
the software could have something to do with the errors, so I excluded
access to the Security folder and subfolders weeks ago, without

I also disabled my registry changes, without effect.

As for the write-cache idea:
I've been having this problem for months, while the harddisk was
connected to:
- the onboard IDE controller
- the onboard S-ata controller (changed disks)
- a PCI S-ata controller card.

I checked the write cache settings just now and there's no way I can
influence them. The box to enable write-cache is greyed out (and
unchecked) and the S-ata controller does not have such an option.

You could very well have a point though, David. I checked my other
computer, also running on Windows 2000, and there are no Scecli and
ESENT errors in the logs. The hardware is entirely different, the
harddisk in the other machine is running on a separate IDE-controller
card. I'd have to check the write-cache settings there too. I'm used
to implementing the same registry changes in both machines, so my
guess that it had something to do with Windows may very well be wrong.

Thanks for suggesting this, at least I've got something to look into


evenOn Mon, 29 Mar 2004 15:24:24 -0700, "Derek Melber [MVP]"

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question