(imported comment written by SystemAdmin)
I mentioned earlier The systems I checked are actually incrementing that registry key, but we are getting the same error. I don’t believe it’s caused by the actual registry write, I also checked the size of the registry and it was well with in the size specification limits
(imported comment written by BenKus)
I spoke with our developers and they said that after the agent writes out this important reg value, it does a registry flush MS API call to make sure the change is committed. If the registry flush call fails, then the agent will report the error noted in this thread. Since you noted that the value is actually updated, we think this is the problem.
What would cause a system to report a failure on registry flush? I don’t know… This is the first that I have ever heard of it…
Regardless, based on the reports in this thread, we have decided to make a change to be more error-tolerant in this area. Instead of simply failing if the API returns an error, we will change the behavior so that the agent will double-check the registry key to see if it was actually updated. Also, it will report some more error messages to report why it failed.
This is a big enough change that we are going to make an test it in the new 8.0 version, which is a couple months away… in the meantime, if anyone has a guess at why these systems would fail their flush registry calls, let us know…
Thanks,
Ben
(imported comment written by arpotu91)
Augh! Just got called out by my management, due to some computers with this problem not appearing in an uptime report. I found a couple of MSDN pages which mention some registry keys related to this… unfortunately, they point to Windows CE, not a server OS… but - maybe there are similar keys on server OS’s? At this point, I really just want to identify servers which could potentially have the problem. Here are the links; not sure they’ll help, but it’s a start…
http://msdn.microsoft.com/en-us/library/ms885460.aspx
http://msdn.microsoft.com/en-us/library/ms885877.aspx
Any chance there will be a 7.x agent released to address this? Maybe a beta agent? I don’t want to give BigFix any unnecessary black eyes.
Arpotu.
(imported comment written by arpotu91)
FYI, did some digging on one of the problematic servers, and found 2 BESClient errors in the application log. Once from each time we tried to start the client:
Event Type: Error
Event Source: BESClient
Event Category: None
Event ID: 17
Date: 4/23/2010
Time: 3:10:19 PM
User: NT AUTHORITY\SYSTEM
Computer: USARTS05-B
Description:
The description for Event ID ( 17 ) in Source ( BESClient ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: Minimum system requirements not met.
…I also found hundreds of the following events in the system log:
Event Type: Error
Event Source: Application Popup
Event Category: None
Event ID: 333
Date: 5/5/2010
Time: 2:05:41 PM
User: N/A
Computer: USARTS05-B
Description:
An I/O operation initiated by the Registry failed unrecoverably. The Registry could not read in, or write out, or flush, one of the files that contain the system’s image of the Registry.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 00 00 00 00 01 00 6c 00 …l.
0008: 00 00 00 00 4d 01 00 c0 …M…À
0010: 00 00 00 00 4d 01 00 c0 …M…À
0018: 00 00 00 00 00 00 00 00 …
0020: 00 00 00 00 00 00 00 00 …
Hope it helps 
Arpotu
(imported comment written by BenKus)
Hi Arpotu,
From the information you sent, it appears that the BigFix Agent is not the only thing having registry access issues on these computers… It appears these computers are having significant issues (although we still don’t know what the issues are)…
Ben
(imported comment written by arpotu91)
Ben, you’re right. Just wish we could figure out what the root cause for these registry problems are. Not much documentation on it, even in MSDN.
Arpotu.
(imported comment written by SystemAdmin)
I found a possible work around for the issue
set the RegistryLazyFlushInterval in the registry to 60 seconds
Reboot
KB317357
http://support.microsoft.com/kb/317357
From Microsoft “Performance problem because of contention on CmpRegistryLock”
–> Configure RegistryLazyFlushInterval in the registry to 60 seconds
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Configuration Manager]
"RegistryLazyFlushInterval"=dword:0000003C
I was able to identify that once I set the RegistryLazyFlushInterval in the registry and rebooted, the problem seemed to be resolved
I have only tried this on 3 servers, with 100% success so far, and the clients have been running for over 2 day now
I would rather not put a work around in place and have to reboot, I would like to get an updated client to fix the issue.
Though this fix may help your developers trouble shoot the problem
Additional Ref:
http://blogs.technet.com/askperf/archive/2007/10/30/troubleshooting-event-id-333-errors.aspx
(imported comment written by USMC175)
I recently ran across this issue as well. Adding the ‘Configuration Manager’ key with associated ‘RegistryLazyFlushInterval’ value {60} did resolve the issue. Client version 7.2.5.22
Is this issue resolved in version 8?
(imported comment written by SystemAdmin)
I have not run across the issue in version 8.0+ yet and I have deployed over 20,000+ clients