Quick Solution: Check the permissions on the root of C: and ensure that BUILTIN\Users have Read access.
Long Story:
8000FFFF == E_UNEXPECTED, not very helpful…
Had a client where windows update was continually failing with the error code 8000FFFF. When looking in the Windows Update log we’d see errors like this:
WARNING: PTError: 0x80248014
Handler FATAL: CBS called Error with 0x8000ffff, <— Checked the CBS.log file but that didn’t give any clues.
Handler FATAL: Error source is 106.
DnldMgr Error 0x8000ffff occurred while downloading update; notifying dependent calls.
AU # WARNING: Download failed, error = 0x8000FFFF
AU # WARNING: Download failed, error = 0x8000FFFF
AU WARNING: BeginInteractiveInstall failed, error = 0x8024000C
CltUI WARNING: AU directive Interactive Progress is exiting due to error 8024000C
And in the event viewer upon each run we’d see these events:
Log Name: Application
Source: ESENT
Date: 7/2/2008 3:05:16 PM
Event ID: 491
Task Category: General
Level: Error
Keywords: Classic
User: N/A
Computer: XXXX
Description:
Catalog Database (1560) Catalog Database: An attempt to determine the minimum I/O block size for the volume "C:\" containing "C:\Windows\system32\CatRoot2\" failed with system error 5 (0x00000005): "Access is denied. ". The operation will fail with error -1032 (0xfffffbf8).
Log Name: Application
Source: Microsoft-Windows-CAPI2
Date: 7/2/2008 3:05:16 PM
Event ID: 257
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: XXXX
Description:
The Cryptographic Services service failed to initialize the Catalog Database. The ESENT error was: -1032.
After seeing this data I did a stare and compare between my root permissions and his and found that he’d modified the c:\ permissions on his system:
His machine:
c:\temp\xcacls c:
C:\ NT AUTHORITY\SYSTEM:(OI)(CI)F
BUILTIN\Administrators:(OI)(CI)F
Mine:
C:\>xcacls c:\
c:\ BUILTIN\Administrators:F
BUILTIN\Administrators:(OI)(CI)(IO)F
NT AUTHORITY\SYSTEM:F
NT AUTHORITY\SYSTEM:(OI)(CI)(IO)F
BUILTIN\Users:(OI)(CI)R <— This is the key one missing that was causing the headache.
NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)C
NT AUTHORITY\Authenticated Users:(special access:)
FILE_APPEND_DATA
The Cryptographic Services runs under “Network Service” which would require Users to have read access. I added BUILTIN\Users with read access to C and all worked again.
Hopefully this post will guide others with similar issues to the solution quickly.
日志名称: Application
来源: ESENT
日期: 2011-12-2 16:00:12
事件 ID: 491
任务类别: 常规
级别: 错误
关键字: 经典
用户: 暂缺
计算机: WIN-MDD2T1PQ4VP
描述:
Catalog Database (264) Catalog Database: 由于系统错误 5 (0x00000005):“拒绝访问。 ”,确定包含“C:\Windows\system32\CatRoot2\”的卷“C:\”的最小 I/O 块大小的尝试失败。此操作将失败,并出现错误 -1032 (0xfffffbf8)。
事件 Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="ESENT" />
<EventID Qualifiers="0">491</EventID>
<Level>2</Level>
<Task>1</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2011-12-02T08:00:12.000000000Z" />
<EventRecordID>31413436</EventRecordID>
<Channel>Application</Channel>
<Computer>WIN-MDD2T1PQ4VP</Computer>
<Security />
</System>
<EventData>
<Data>Catalog Database</Data>
<Data>264</Data>
<Data>Catalog Database: </Data>
<Data>C:\</Data>
<Data>C:\Windows\system32\CatRoot2\</Data>
<Data>-1032 (0xfffffbf8)</Data>
<Data>5 (0x00000005)</Data>
<Data>拒绝访问。 </Data>
</EventData>
</Event>
而且直接配置文件是效率最高的,通过其它驱动效率都相对较低,BDB
这个测试不太准确,看官方的测试结果:http://bind-dlz.sourceforg
为什么使用BDB时QPS这么低? 我在bind版本基本相似的环境中测试的
It is quite useful and interesting too.
VIRT 的上限是64G,也就是36位, cat /proc/cpuinfo的结果是:addre
昨天要准备用线程重写webbench,试验了下Fedora Linux 2.6.35.14
不明白您的具体的意思是什么?
已经发送到你QQ邮箱