Exception on startup in CEF 3497.1829

[callum]

My Win64 C++ app builds and runs successfully with CEF 3359 but today when I updated the version of CEF it builds against via the Spotify builds to 3497.1829, it triggers an exception when calling CefBrowser::CefFrame::LoadURL(url) even though the CefBrowser and CefFrame instances and the url appear to be valid.

The stack just contains calls to libcef.dll.

I've upgraded the version of CEF dozens of times in the past and apart from some minor interface tweaks, it's painless and works as expected.

Was there something fundamental that changed between 339 and 3497 - different code I need to call at initialization perhaps? I could use some help narrowing down where in the CEF code to start looking.

[magreenblatt]

What is the symbolized call stack for the crash?

[callum]

I tried to get that by downloading the libcef.dll.pdb file from the same location and selecting "Browser and find libcef.dll.pdb" from the exception screen. When I do that, I'm told that "A matching symbol file was not found in this folder."

Using 64 bit Debug configurations throughout and versions of CEF and symbol files from Spotify match.

What am I doing wrong?

[magreenblatt]

Did you download the pdb file for the same version and architecture?

[callum]

Yes, that's what I mean by the last sentence I wrote - both the CEF bundleI build against and the Debug symbols are version 3.3497.1829.g004ef91_windows64

[callum]

Are PDBs compatible across versions of Visual Studio - I am using VS2013 but I expect CEF is built with a more recent one - VS 2015 or even VS 2017 ?

[magreenblatt]

Forwards compatible but possibly not backwards compatible. You can install VS2017 or WinDbg for free.

[callum]

That's probably it then.

Our main product is built against 2013 and every time I've tried to install a different version side-by-side, things break and I end up having to reinstall Windows to get back to a working version.

Updating to 2017 is on our roadmap - sounds like doing that is a pre-requisite for updating the version of CEF we build against.

[ndesktop]

You may want to verify if libcef was built with fastlink. In this way you need also the .obj from the VS libcef was built with.

This causes many problems for me, this is why I am building with fastlink on false, even if full pdb generation and link takes up to 30 GB on my dev machine.
But at least I know I see the truth in debugger.

[callum]

Understood and thanks for the tip.

I wonder if the Spotify builds changed to VS 2017 between 3359 and 3497 and that's why my app throws the exception in the first place. I've had no issues using a 2015 CEF build with 2013 for many update iterations but maybe that changed in the newer version.