I see you solved your own problem. However, I would like to explain what are you looking at, and what to look for in an error log like the one you received, in case you get a similar error in the future.
There are many type of error logs, and this one is quite low level. It is difficult to understand what the problem is with a large game with such an error log, but there are some clues you may use to help yourself.
The first line is the Unity Player version. This is relatively important, as an error may be linked to a precise version of the player that you're using. In general, always try to make sure you're using the last version of Unity to make your games.
Then you get the error type and location. In this case, the error is:
test 8.exe caused an Access Violation (0xc0000005)
in module test 8.exe at 0023:01275744.
In here, you can see that the error is an access violation, which corresponds to code 0xc0000005. Regardless of the error code, it might be useful to search online for it, and that way you can at least know whether or not the error is related to your program or not.
In this case, in Windows, error 0xc0000005 may be related to closing handles that are currently in use, that is, you're using a handle in one thread and you're closing it in another at the same time. If you're not doing anything like this, then it is likely that this is an error in the player itself.
Then you see the module that caused the error, and the program location. In this case, the module is 8.exe, which is the same executable file. It is perfectly possible that the error was not caused in the executable file, but in a DLL that you loaded.
The next section is some general information regarding to the state of the machine when the error happened:
Error occurred at 2015-11-01_000136.
D:\..........\8.exe, run by Foo.
32% memory in use.
0 MB physical memory [0 MB free].
0 MB paging file [0 MB free].
0 MB user address space [3746 MB free].
Read from location 7220799c caused an access violation.
If you see something like "100% memory in use", you may want to think that the problem was caused by filling up the memory.
Also, you can see that the actual error happened when trying to read from memory location 7220799c. This seems to be a normal memory location, but if the conflicting address was 00000000 or something like that, then the problem is a null pointer access.
Then you see the runtime context. This contains the CPU registers, the bytes at CS:EIP and the stack. These are snapshots of several parts of the computer at the exact moment the program crashed.
First you get the CPU registers. Unless you have a disassembly of the program, it's very difficult to diagnose something like this, but if you see EIP (Instruction Pointer) set to 0, then it probably means you're calling a null pointer. Also, if EBP (Base Pointer) and ESP (Stack Pointer) are vastly different, then it probably means you had a stack overflow.
Then, you get the bytes at CS:EIP. This is what the instruction pointer is pointing to. This is the actual program code that was meant to be executed. Not much to see here, but you may want to decode the actual bytes and see what the actual instruction is about. In this case, f3 0f is a "Shift Packed Data Left Logical" MMX or SSE2 instruction. If you see something like pure zeroes or pure fs in here, then it probably means you're executing invalid code. Check the value of EIP in the context above.
Then you get the stack. The currently active stack frame is what you have from EBP to ESP. In this case, there is not much to see here, but if for example, you see a truncated large text in there, then it is possible that you are experiencing a stack overrun.
Finally, you get a list of the modules that are loaded into memory with your program. Look at this list to find DLLs that you are not expecting (like viruses, or antiviruses), or old versions of DLLs that you are expecting.
