Icaros's FLAC thumbnailing option is probably for cover-art.
I had a look at the crash dump and two things stand out to me:
[ul][li]The crash looks like a Variant or PropVariant containing invalid data is being returned by something, and then copied, causing an invalid memory access.
I can't see much else of use from the dump, unfortunately, but if it was me I'd be looking for code which passes uninitialised Variants/PropVariants to APIs which assume they have been initialised, or code which does the opposite and assumes it is being passed initialised Variants/PropVariants from APIs which don't guarantee that (which can happen with strict "out" parameters, from memory). It could also be a problem of the data a Variant/PropVariant points to being freed and then the Variant/PropVariant being passed to something which tries to store/copy the now-freed data.
[/li]
[li]Icaros is a shell extension written in .Net. This is dangerous and against Microsoft's rules (even with .Net 4.0).
It causes the .Net runtime to be loaded into every process that shows a File Open dialog, and that can cause crashes and other conflicts if other things within a process need a different version of the .Net runtime or if they simply conflict with .Net itself. (e.g. The process itself, or another shell extension written in .Net against the rules, may require a different version of .Net be loaded.) Even ignoring the potential crashes and conflicts, it's inefficient to load the big .Net runtime into lots of processes that don't need it.
While .Net 4.0 allows some limited side-by-side usage of different runtime versions, it doesn't actually solve this issue and Microsoft still say shell extensions should not be written in .Net.
Icaros can still keep most of its code in .Net, but it needs to move that code into a separate standalone .Net process and have a "shim" shell extension written in C++ (or similar) which talks to the .Net process. That's the only Microsoft-supported/recommended way to "write shell extensions in .Net", and apparently how they write some of their own ones. (It's not strictly "writing a shell extension in .Net" because the shell extension itself is C++.)[/li][/ul]
I'd recommend narrowing down the .FLAC files required to reproduce the crash to the smallest set and then sending them to the Icaros developer(s) to see if they can reproduce the problem with them. The issue may only be triggered by specific files.
Also, see if you can get Explorer to crash by opening the Properties dialog for the same FLAC files, one after the other. The IcarosPropertyHandler.dll extension is normally only loaded and called on the FLAC files when the Properties dialog is opened for them (that's what I see with a default Opus configuration), so you may need to do that to reproduce the crash. I'm guessing you have Opus configured in a way which is causing the properties to be read via another route, which may be why you see the crash with the FLAC files but it takes more effort for someone else to see the same.
But they should also really think about moving their .Net code into a separate process and replacing the shell extension with a C++ shim which talks to that process, as what they are doing is against the rules. It may or may not be involved in the crash you are seeing, but it's likely to cause other problems either way.
[ul][li]Is it supported to write Windows Shell Extension using .NET 4 today?[/li]
[li]Create a Shell Extension Handler thumbnail extractor with .net?[/li][/ul]
Note that Microsoft have published guides on writing .Net shell extensions in the past, but then had to update them with big red text saying "Do not do this!" when people who knew about the problems shouted at someone behind the scenes. 
e.g. Create Namespace Extensions for Windows Explorer with the .NET Framework