You have, in essence, eliminated a LOT of things external to the database. (Which is good, by the way, because it drastically narrows the playing field.)
The fact that it sometimes crashes when you manually open the report means that the problem isn't in the code that launches the report. It is EITHER the data driving the report or it is the report structure itself. Intermittancy makes me think it is data-centric, but there is still an outside chance of something else.
We are looking for reasons why a report might blow up. So we have to look at all of the levels of things that contribute to the creation of the report on-screen. This kind of debugging is tedious, but if you aren't getting any error messages of value, it is the only way I know to narrow it down.
By any chance, does the report have a class module with some report formatting or statistical code in it?
Do you have warnings turned off in your database? If so, turn them on again for the purpose of debugging.
Is there a named query that is the recordsource of your report OR did you build the report from scratch using the report wizard, which will build a query for you?
A) If there IS a named query, can you open that query and, if so, do you see any oddball characters, <NULL> cases, or anything like #name, #value, or some other hash-tag note in one of the fields in the query?
B) If there is NOT a named query, can you open the .Recordsource of the report, copy that query, use the query designer in SQL mode, and MAKE a named query out of it, then apply the previous test? (What you want is to be able to see the data stream that is feeding the report.)
Out of curiosity, when you manually open the report and it crashes, can you go back and bring it up in Print Preview mode, then step through the pages until it crashes? If so, trial and error might let you localize it to a record or group of records. If it crashes immediately in Print Preview, that doesn't tell us much, but if it crashes on a later page, that tells us A LOT.
There is one other thing we can try that might help. It's a long shot, but heck, if it pays off we can narrow stuff down really well. If your version of Windows has a clock gadget for the desktop, enable it. If/when Access crashes on your report, immediately note the time on the gadget.
Here is the long shot: Open Control Panel >> Administrative Tools >> Event Viewer. You will have the option to view several event log streams. For Win7, you can see under WINDOWS logs; look in the SYSTEM, APPLICATION, and SECURITY logs. Under Applications and Services logs, look in the ACEEventLog and the Hardware Events.
ONLY look for events at the date & time you noted when the report crashed, no more than two minutes either way of that time. Since both the clock gadget and the event logs take their times from the same internal source, the time you noted on the gadget will correspond to times in the event logs. What you are looking for is something that occurred at or within several seconds of the application crash. If you get more than two minutes away from the event with no results, it ain't there to be found.
You will probably see a task or process exit. You MIGHT see some other errors. If you do, there will be a status code of some type that might or might not be translated to text. If it says something about MSACCESS.EXE exiting or aborting, that is a significant event log and might be relevant to the problem.
If you can't find anything like that, it is OK because Access can crash in other ways. But if you get lucky, it crashed in a way that left behind a trail. In which case we need to know the exiting status code, which will start with 0x8 plus 7 more hexadecimal digits. You probably won't see a 0xC plus 7 more digits because the 0xC... errors usually cause a Blue Screen of Death.
