The following boot-start or system-start driver(s) did not load: dam

It has been a while since these were posted; however the problem still shows up from time to time.
dam or DAM refers to the Desktop Activity Moderator. It moderates various aspects of desktop activity, and if one or more of the activities fails to start during startup, this error can be reported along with other areas that may clue the individual on what is causing it. Examples: One of the tiles is disabled, and therefore won't update: like news and such. Other activities which may be disabled include activities normally found on laptops and tablets, power saving, clock updates etc., nothing big! If the system waits on the dam, it may miss something stuck in the pile making the dam and fail to report that!

This is handled through the SCM, Service Control Manager, and I have been reading that the SCM can be a bit skittish. For example, if at startup, several services and such are handled by the SCM. If one or more of these doesn't respond in a timely manner that it has loaded, SCM will generate the DAM error or an other SCM error, even though that service may later come online. So, it seems we could be getting a lot of false positives. Add to that tidbit, little information is available about DAM, and too much on the SCM and what you have appears to be a bottleneck. (In other words, dam error shows up a lot for a lot of things) Informational! If it doesn't show up every time, but only shows up periodically, examine the other events... and you may discover under the informative events certain things coming online after the event. Either way, it's not important like errors. Warnings are more than informative because something in the OS may not behave as intended without whatever the warning was... and Critical is sure to be causing clearly observable problems.

It could be a coincidence that if one examines all the startup activities happening at boot (and that's when dam shows up... most of the time), and that the OS may run into work piling up faster than the processor and memory can handle it, these processes kind of pile up to make a dam. And like a dam, water still flows, and things still get through, but if it floods, the dam can break... but according to various reads... only temporarily, or forever, if the particular process has been disabled; if you notice... the event is only informational, and not an error or critical error. Systems today do not do work linearly like in the old days... so some things may get tied up before the thing that needs it. There are multiple threads or actions happening simultaneously.

Here's an example from my machine:
First we get an error: The tib_mounter service failed to start due to the following error: The service cannot be started, either because it is disabled or because it has no enabled devices associated with it.

This occurred because I didn't have my USB Hard Drive plugged in. Not plugged in, and therefore it doesn't need the drivers installed for it right now, and a 0.02 seconds later... we get....

The following boot-start or system-start driver(s) did not load: dam (Says it's dam = Desktop Activity Moderator, but also I've seen dam = Device Access Manager... go figure.) one good acronym is as good as another.

In programming we can often handle these types of problems with a sweet little routine that gets placed in a loop. In the old days... things happened in an orderly fashion, nowadays, you call an API, and then loop to monitor it. Only the problem is, in machine language it's stuck in the loop, so if your waiting, unless it's some kind of run in the background housekeeping thing, you're stuck. So, a process exists that you can place in the loop that basically tells the machine... go do your thing, and come back when you're done, so while in the loop, other processes are busy taking care of business, while you wait for the specific thing you're waiting on to finish up before you proceed. Sweet. But, often in a booting process, like startup, and boot from bootstrap, you can only put one foot in the boot at a time, other processes may not be available. So, what happens is if something needs something, and it's not there, it reports it even though later it may become available. If everything was in the queue, and waiting to process, eventually it all completes. Not as clean as one would like, but it works. Think of it like when debugging, one may set up little messages that tells you what's getting done, and it's just informational, unless there's an issue.

So, I'd say: Don't get hung up on informational events, that's all they are, there to help if something goes wrong, and you will drive yourself silly trying to track down and "fix" something that is intended not to be fixed.