STG_E_NOTSIMPLEFORMAT (0x80030112) — Stop the STGM_SIMPLE Flag Error
This error happens when code or a tool tries to open a compound file without the STGM_SIMPLE flag. The fix? Re-open the file with that flag, or recreate it as a simple stream.
This error is a flag mismatch
You're getting STG_E_NOTSIMPLEFORMAT (0x80030112) because something — your code, a legacy app, or a script — is trying to open a compound file that wasn't created with the STGM_SIMPLE flag, but the open call expects it. I've seen this mostly with older CAD tools and custom document managers that use OLE structured storage internally.
The real fix: match the flag
There are two paths depending on whether you control the code that creates the file or just the code that reads it.
Path A — you write the file
When you create the compound file with StgCreateStorageEx, pass STGM_SIMPLE | STGM_READWRITE | STGM_SHARE_EXCLUSIVE as the grfMode. The key value is 0x08000000 for STGM_SIMPLE. Here's a concrete example:
IStorage *pStorage = NULL;
HRESULT hr = StgCreateStorageEx(
L"C:\\data\\myfile.cmp",
STGM_SIMPLE | STGM_READWRITE | STGM_SHARE_EXCLUSIVE,
STGFMT_STORAGE,
0,
NULL,
NULL, // riid for IStorage
&pStorage);
if (FAILED(hr)) { /* handle error */ }
Once the file is created with STGM_SIMPLE, any subsequent StgOpenStorage call that also uses STGM_SIMPLE will work. The reason: the flag is baked into the file's header structure. Windows marks the storage as “simple format” on disk.
Path B — you only read the file
If you didn't create the file and it's giving you this error, you need to open it without the STGM_SIMPLE flag. That's the real cause here: the read call is passing STGM_SIMPLE when the file wasn't created that way.
IStorage *pStorage = NULL;
HRESULT hr = StgOpenStorage(
L"C:\\data\\existingfile.cmp",
NULL,
STGM_READ | STGM_SHARE_DENY_WRITE, // no STGM_SIMPLE
NULL,
0,
&pStorage);
if (SUCCEEDED(hr)) { /* use pStorage */ }
Drop the STGM_SIMPLE flag from the read call. The file's own header determines the internal format; you don't need to force it on the read side.
Why the error happens at all
The compound file format (OLE structured storage) has two flavors: standard and simple. Simple mode is an optimization — it trades away some features (like transacted mode and direct child storage access) for faster streaming of large data. When you open a standard-format file with STGM_SIMPLE, COM's storage layer checks the file's header and says “this isn't a simple-format file, I can't give you a simple storage object.” That check returns STG_E_NOTSIMPLEFORMAT.
What's actually happening here is a mismatch between the file's on-disk format and the open-mode flags. The OS isn't broken; it's enforcing a constraint that prevents you from misusing the storage object.
Less common variations
I've run into this error in three other scenarios you might not expect:
1. DirectShow filter graph file loading
Some older DirectShow graph editors (like GraphEdit from Windows SDK 7.x) use StgOpenStorage internally with STGM_SIMPLE when loading .grf files. If the .grf was saved by a newer tool (Windows 10's GraphStudioNext), it may not be in simple format. The fix: re-save the graph file using the original tool, or use IFilterGraph::LoadFromFile instead.
2. OLE document embedding in MFC apps
MFC's COleDocument sometimes passes the STGM_SIMPLE flag when serializing embedded objects. If you're mixing old MFC code with modern C++ and calling Serialize on a storage that's not simple, you get this error. The workaround: change the creation mode to include STGM_SIMPLE, or bypass the MFC serialization and use raw IStream reads.
3. Third-party virtual disk containers
A few disk imaging tools (e.g., early versions of Virtual CloneDrive) use compound files as their container format. If the container was created by a version that didn't set STGM_SIMPLE, and the tool's newer version tries to open with STGM_SIMPLE, it chokes. This is rare but nasty because you can't change how the tool is coded. The workaround is to recreate the container with the current tool version.
Prevention
Three rules to keep this error out of your life:
- Be consistent. If you create a file with STGM_SIMPLE, ALWAYS open it with STGM_SIMPLE on the same file. Never mix flags across create and open.
- Log the mode. In your storage wrapper class, log the
grfModeflags when creating and opening files. I've caught mismatches this way on the first test run. - Test with actual files. Don't assume all compound files are in simple format. If you're writing a tool that reads third-party data, fall back to opening without STGM_SIMPLE if the flag-first attempt fails.
One more thing: avoid the temptation to blindly catch this error and retry without the flag. That masks the real problem — you're using the wrong API for the file format. Fix the flag, don't paper over it.
Was this solution helpful?