For windows you shouldn't need to "track" patch levels of the OS as that can be queried at any time via WMI. If you are following change management you can do a global query before and after a change to verify the results of an OS patch. (make sure the MSI provider is installed)
Driver updates should be tracked (wmi can be used to query them but it's not worth the effort to try to catch them all)
Software application updates should be kept in the CMDB but (except for initially) should come from change management
If you really wanted to track registry changes set a group policy to enable file and object access and choose which keys to audit (http://support.microsoft.com/kb/324739). This isn't for a CMDB but will allow you to track who is making changes.
So that's what folks typically want to track in a CMDB and why it's sometimes not a good idea so what should go into a CMDB. The answer is it depends. An ITIL defined CMDB may or may not care about machine configs unless that particular machine config pertains to a service. ACMDB might also contain an asset tracking solution (for things like hardware config location and warranty info) but is more about relationships of a particular Configuration Item to other CI. Relationships include things like "is responsible for", "is connected to", "depends on" and (more difficult but in many cases more important) "required for SLA tier_". In short, record what's required to recreate the service - not the server.
For example. If email was the service I'd list things like:
64 bit CPU, 3gb of ram (based on # of users on @today) 7gb of space for server install, 100 gb of storage for exchange dbs and recovery (based on usage as of @today), dvd rom drive.
Software: Server 2003 R2, Exchange 2007 SP2, MPIO drivers for the SAN
CMDBs are not typically for server admin usage. Admins will be far happier with an asset management solution.