I had a look at semaphores and their uses in windows and they apparently limit the amount of threads that can access a resource. Windows semaphores work by counting. Threads enter the semaphore by "calling the waitone method". Once the call is returned the semaphore count goes to 0 and is then blocked so that no other threads can enter. When a thread releases the semaphore, the next thread may enter.
Possible reasons for sempahore timeout are (from IBM page):
1. A heavy load on the server is causing processes to be delayed from releasing semaphores.
2. A process has crashed while holding a semaphore, causing other processes to block when trying to acquire the semaphore.
3. Deadly embrace, semaphore contention where two tasks are waiting on each other and neither task is able to break the loop. In the simplest case, thread A is trying to get a semaphore which is owned by B, while B is trying to get a different semaphore which is owned by A. More complex combinations are also possible: A wants a semaphore owned by B, who wants a semaphore owned by C, who wants a semaphore owned by A, etc.
4. If a process was to fail to set a semaphore during execution, another process dependent on the semaphore will be blocked awaiting the semaphore.
Perhaps someone could make sense out of why locking the SD card prevents this error. Perhaps it is something to do with the third one? I have no idea though.