I have successfully opened and analyzed many dump files larger than that.
Whenever I have had any issues with DebugDiag I try to open the dumpfile in Windbg which usually gives better information if it fails to open the file.
In my own experience the 3 issues that I have come across the most are:
- The Dump File was not fully generated. I didn't have enough diskspace for the full dump operation to complete dumping out all of the streams so I had a "valid" .dmp file in explorer but if I opened it in Windbg it gave me a better error that I was missing some streams. Note that Antivirus has also caused similar issues not allowing the full dump to complete.
- Everynow and then I come across a .Net process dump where the version of the CLR/DAC in the dumpfile aren't happy with any symbols I have. I try openening it in different tools like Visual Studio, Windbg or Jetbrains dotMemory etc and I can sometimes get what I need from one of those.
- And of course every now and then I get dumpfile that of a 32bit process taken by 64 tool like TaskManager. Usually you will see errors about your debugger not being a valid win32 program or something like that when this happens.
One last silly thing to check is make sure if you downloaded your dumpfile from the internet (ie from Google Drive OneDrive) is to make sure you right click on the .dmp file -> properties and make to "unblock" the file . I have had a few incidents where a file marked as being downloaded over the internet and "blocked" would cause odd behaviors and sometimes comoplete failures.
I have always had the most luck by opening dump files outside of DebugDiag where sometimes I am able to do enough analysis with what I already have or I at least will get a more informative error to work with ( hopefully you don't have to get another repro-dump and using above can get your somewhere too)
Good luck!