[NTOS:CM] Remove orphaned KCBs of keys during normal hive unload A hive whose KCBs have a reference count of 0, meaning nobody is using these keys anymore, will not get removed from the cache table. As a result during a normal hive unloading operation you will get orphaned KCBs which results in an unload failure. This is wrong, because this is what a normal hive unloading is supposed to do. What it cannot do of course is that it cannot scramble the references of opened keys by the users who use the Registry, as it is the job of force unloading mechanism to do that. Also remove a misleading debug print. Force unloading works as intended by scrambling the references of keys and marking the KCB for deletion, which is what how a force unload works. Namely Windows does exactly that. CORE-10705
[NTOS:CM] Lock the cached KCB before removing it from cache entries - Annotate the CmpEnumerateOpenSubKeys function with SAL2 - When removing an orphaned cached KCB, ensure that it is locked before clearing it from cache table entries
[NTOS:CM][CMLIB] Minor code styling In particular remove some extra-parentheses around single code tokens, and replace few "DPRINT1 + while (TRUE);" by UNIMPLEMENTED_DBGBREAK. + Improve some comments.
[NTOS:CM] Implement support for alternate registry hives Sometimes repairing a broken hive with a hive log does not always guarantee the hive in question has fully recovered. In worst cases it could happen the LOG itself is even corrupt too and that would certainly lead to a total unbootable system. This is most likely if the victim hive is the SYSTEM hive. This can be anyhow solved by the help of a mirror hive, or also called an "alternate hive". Alternate hives serve the purpose as backup hives for primary hives of which there is still a risk that is not worth taking. For now only the SYSTEM hive is granted the right to have a backup alternate hive. === NOTE === Currently the SYSTEM hive can only base upon the alternate SYSTEM.ALT hive, which means the corresponding LOG file never gets updated. When time comes the existing code must be adapted to allow the possibility to use .ALT and .LOG hives simultaneously.
[NTOS:CM] Use the appropriate flags on functions that will call CmCheckRegistry & add missing CmCheckRegistry calls In addition to that, in some functions like CmFlushKey, CmSaveKey and CmSaveMergedKeys we must validate the underlying hives as a matter of precaution that everything is alright and we don't fuck all the shit up.
[NTOS:CM] Cleanup the hive in case linking it to master fails (#4969) Currently the failure code path doesn't do any kind of cleanup against the hive that was being linked to master. The cleanup is pretty straightforward as you just simply close the hive file handles and free the registry kernel structures. CORE-5772 CORE-17263 CORE-13559
[SDK:CMLIB][MKHIVE][BOOT:ENVIRON][NTOS:CONFIG] Add missing HvGetCell casts. Replace some ASSERT(FALSE).
[NTOS:CONFIG] Release the lock in a failure case in CmLoadKey This is a workaround, the real issue is still not resolved CORE-17263
[NTOS:CONFIG] Comment out the assertion until fixed CORE-17263
[NTOS:CM] Set and reset the CMHIVE HiveIsLoading flag adequately. Fix an assertion in CmFlushKey() and reset the CMHIVE ViewLockOwner when releasing the view lock.
[NTOSKRNL] Reduce noise
[NTOS:CM] Implement more support for force-unloading registry hives. CORE-13448 CORE-10705
[NTOS][MKHIVE] Minor code formatting.
Git conversion: Make reactos the root directory, move rosapps, rostests, wallpapers into modules, and delete rossubsys.