Thanks for a bug report. I'm moving this to evolution-ews, because the crash happened just there.

From a brief code reading around the place of the crash:

   /* Check if the item has really changed */
   if (!strcmp (((CamelEwsMessageInfo *) mi)->change_key, id->change_key)) {
      camel_message_info_free (mi);

either the first or the second is NULL, or points to uninitialized/already freed memory.

This happened again, and definitely not related to suspend/sleep cycles. Evolution was left open during the night, and this crash happened after about 30 minutes of usage this morning.

Oh, pity. As I guess you have it running under gdb, could you print few variables, please? Namely (from gdb):
   p *((CamelEwsMessageInfo *) mi)
   p *id
   p *item
   p *item->priv

which may help identify the issue, or at least give some hints on the background.

I'm not sure I'm doing it right, because gdb can't display the values, e.g.

(gdb) p *item
No symbol "item" in current context.

Which happens for all the p commands.

Oh, right, I think I know what is going on. If your backtrace looks the same as at comment #0, then you need to switch to the frame where sync_updated_items function is.

As for the above backtrace:
> #0 __strcmp_ssse3
>    at ../sysdeps/x86_64/strcmp.S line 209
> #1 sync_updated_items
>    at camel-ews-folder.c line 1246
> #2 ews_refresh_info_sync
>    at camel-ews-folder.c line 1537
> #3 camel_folder_refresh_info_sync
>    from /usr/lib64/libcamel-1.2.so.45
>...

the sync_updated_items is at frame #1, thus you first switch to it in gdb with:
   f 1
then the print commands should work properly.

Thanks, that helps!

Here's the output that I get (with some strings changed to not reveal personal information)

(gdb) f 1

+ Trace 233134

$1 = {info = {summary = 0x7ffeee9aaef0 [CamelEwsSummary], refcount = 4, 
    uid = 0x7fff895243b0 "AAMkADlmNzBlZDU3LWJhYjQtNDQ2YS05N2Q4LWZhNGQ2MjA1YzhlZABGAAAAAACw8cUlyrMkTbHRu2mvt/pmBwClMfetaApeQIZ+JyvwvfvQAXNfr3akAACSAY4eghnQT7TVqVG9LiEiAAAlJ2bAAAA=", dirty = 0, 
    subject = 0x7fff9004feb0 "BLA BLA SUBJECT", from = 0x7fff9004f760 "Robert Munteanu <rmuntean@blabla>", to = 0x7fff84df50b0 "Bla Bla <blabla@blabla>", 
    cc = 0x7fff9004ff10 "Bla 2Bla <bla2bla@blabla>, Bla 3Bla <bla3bla@blabla>", mlist = 0x0, flags = CAMEL_MESSAGE_SEEN, size = 16056, date_sent = 1391693115, date_received = 0, message_id = {id = {
        id = 14988862593010753030, hash = "\006ދ+\035#", <incomplete sequence \320>, part = {hi = 730586630, lo = 3489866525}}}, references = 0x7fff8a0875a0, user_flags = 0x0, user_tags = 0x0, content = 0x7fff8a037000, headers = 0x0, 
    preview = 0x0, bodystructure = 0x0}, server_flags = 0, item_type = 0, change_key = 0x0}
(gdb) p *id
$2 = {id = 0x7fff18a34a90 "AAMkADlmNzBlZDU3LWJhYjQtNDQ2YS05N2Q4LWZhNGQ2MjA1YzhlZABGAAAAAACw8cUlyrMkTbHRu2mvt/pmBwClMfetaApeQIZ+JyvwvfvQAXNfr3akAACSAY4eghnQT7TVqVG9LiEiAAAlJ2bAAAA=", 
  change_key = 0x7fff18667110 "CQAAABYAAACSAY4eghnQT7TVqVG9LiEiAAAlQG0S"}
(gdb) p *item
$3 = {parent = {g_type_instance = {g_class = 0x7fff1808efe0}, ref_count = 1, qdata = 0x0}, priv = 0x7fff18a15bf0}
(gdb) p *item->priv
$4 = <incomplete type>

Thanks for the update. I see it now, the locally stored message info doesn't have stored the 'change_key', it's NULL. All objects are alive with proper data, thus I'll simply fix this with better checking on evolution-ews side.

As a workaround, you can drop local cache and let evolution redownload everything from scratch. You can find the local cache at
   ~/.cache/evolution/mail/<ews-account-uid>/
you can recognize the right folder by its content, the EWS account contains file named 'folder-tree'. The folders.db file contains local cache, where you can delete table of the same name as the folder in which this crashes, to avoid complete account information download, but I'm afraid it's safer to just move away whole cache (or folders.db file itself) and then start evolution.

Created commit 34e0db4 in ews master (3.11.90+) [1]
Created commit a249b95 in ews gnome-3-10 (3.10.4+)

[1] https://git.gnome.org/browse/evolution-ews/commit/?id=34e0db4

Great, thanks for the fix!

I'll set some time for the clear/redownload, as I have quite a large account.