Is this will never be official binary release to change?
To be clear, offset reported by Windows for libevent-2-0-5.dll is from tor-win32-0.2.6.10.zip (built with Tor Browser 5.0), not from tor-win32-0.2.7.6.zip. (they used the same mingw tag however, but offsets are different).
Please test it with unpacked binaries for tor-win32-0.2.7.6.zip
New Windows Build might to uncover some bug in dlls, Microsoft could to cover it back in next build or not.
So what about dll entry point:
The entry-point function should perform only simple initialization or termination tasks. It must not call the LoadLibrary or LoadLibraryEx function (or a function that calls these functions), because this may create dependency loops in the DLL load order. This can result in a DLL being used before the system has executed its initialization code. Similarly, the entry-point function must not call the FreeLibrary function (or a function that calls FreeLibrary) during process termination, because this can result in a DLL being used after the system has executed its termination code.
Because Kernel32.dll is guaranteed to be loaded in the process address space when the entry-point function is called, calling functions in Kernel32.dll does not result in the DLL being used before its initialization code has been executed. Therefore, the entry-point function can call functions in Kernel32.dll that do not load other DLLs. For example, DllMain can create synchronization objects such as critical sections and mutexes, and use TLS. Unfortunately, there is not a comprehensive list of safe functions in Kernel32.dll.
Calling functions that require DLLs other than Kernel32.dll may result in problems that are difficult to diagnose. For example, calling User, Shell, and COM functions can cause access violation errors, because some functions load other system components. Conversely, calling functions such as these during termination can cause access violation errors because the corresponding component may already have been unloaded or uninitialized.
Because DLL notifications are serialized, entry-point functions should not attempt to communicate with other threads or processes. Deadlocks may occur as a result.
It doesn't crash inside crt (for exe either), but LoadLibrary fails instead.
Wrong assumption, probably, still about crash. How is it crashing, logs by windows, and message boxing after that?
@gk:
Have you confirmed that TBB is responsible for crash?
Win10IP is a beta and build 14251 is on fast ring (like "pre-beta"). MS known issues:
Due to a recent memory management change, you may see periodic app crashes or other memory related app errors. Rebooting your PC may correct the issue. Due to this issue, the Github client will not launch.
So, maybe, wait for beta stage at least to make conclusions?