Looks like there are some paths to find out if dwrite is enabled, which inits gfxPlatform, which requires information from PopulateScreenInfo[1], which depends on the refresh driver existing. At this time however, we haven't initialized our vsync source so we crash. This moves vsync initialization earlier in the gfx pipeline.
[1] http://searchfox.org/mozilla-central/source/gfx/thebes/gfxPlatform.cpp#749

Comment on attachment 8897469[details][diff][review]
Init VsyncSource before PopulateScreenInfo
[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:
User impact if declined: Startup Crash
Fix Landed on Version: Firefox 57
Risk to taking this patch (and alternatives if risky): See blow
String or UUID changes made by this patch: None
See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.
Approval Request Comment
[Feature/Bug causing the regression]: Unsure, vsync has been around since Firefox 40 or so.
[User impact if declined]: User startup crash
[Is this code covered by automated tests?]: Yes
[Has the fix been verified in Nightly?]: No, as this crash only happened in ESR.
[Needs manual test from QE? If yes, steps to reproduce]: No
[List of other uplifts needed for the feature/fix]: None
[Is the change risky?]: Moderate
[Why is the change risky/not risky?]: Generally, vsync is always required to run Firefox. However, the ordering of things in startup isn't as defined as other parts of the system and this could cause random changes in timing that wasn't apparent before. This just moves initialization of one component from early in startup to slightly earlier in startup.
[String changes made/needed]: None

(In reply to Gerry Chang [:gchang] from comment #9)
> Hi :mchang,
> If the crash only happened in ESR, why do we need to uplift this to Beta56?
> Can we let this ride the train and not fix in 56?
And it's still a start up crash. I still saw some crashes in 56 when digging through the crash reports so it'd be nice to fix those.