Are you sure your pc woke up from sleeping, or could it be, that your PC used hibernation instead?
When a pc exits hibernation then applications/functions (BitBlt) may try to access memory pages that aren't currently loaded,
which i suspects is the cause of the above issue.
(This would also explain, why tests with sleep mode couldn't reproduce this issue.)
When changing the user, the source/target device context could become kind of unreachable (for each other) because both contexts are getting remapped to a virtualized display (the other user shall not see your desktop, ...).
The two device contexts are located in different processes (cmd and cmdbkg), so it is plausible that they are remapped at different time points.
But you really have to change the user (logout process must have been started) to have a chance to see this issue;
i'm a bit unsure because i don't get it how you mean this exactly:
misol101 wrote:(I didn't actually change user, just returned back to the one I had)...
Other possible reason of such an issue were listed in Remarks section in the https://msdn.microsoft.com/de-de/library/windows/desktop/dd183370(v=vs.85).aspx
, and could be encouraged by high cpu load / a (temporarily) blocked cmd windows (virusscanner, ...), and other "slowing effects".
Default solution (for all reasons): Try again (later), as you actually do.
One could count the fails in row to be sure there is no serious other problem (hung cmd.exe, ...) on which you may (or may not) want to exit cmdbkg.