Quote Originally Posted by OWM View Post
It defaults to Program Files (x86) for the installation path for legacy reasons (first alpha builds were 32 bit), but the actual app is 64 bits.
It's clear that installing in Program Files (x86) does not define an app as being 32-bit. I have figured out what in my installation caused limited memory access. The process might give you some useful information. But maybe not, too, because I use protective software on our computers that probably isn't on most other users' machines.

1) I did not install the demo version as an administrator. I ordinarily do that when I install something, but I simply forget the step when installing the demo. I realized that right away, but since the demo seemed to run, I thought, Okay.

2) I used monitoring software to check performance. I opened the OWM demo and began piling 3rd party PNG symbols, each with a size of >100 MB, into the test map. Every time the memory monitor showed it was nearing 4 GB capacity, OWM crashed with a freeze. The monitor showed no noticeable change within the upper 60 GB of memory. There were no error messages. The program simply became inactive and the Windows 10 Pro task manager reported that OWM was not responding. I killed the dead session with the task manager.

3) The combination of the Program Files (x86) installation with the crashes at <4 GB memory usage led me to believe that I'm dealing with a 32-but app. I did no additional checking to see whether I was running on a 32- or 64-bit level.

4) Last night, I uninstalled the demo, manually checked for registry entries, erased those that were there, rebooted and installed the demo again, this time running the installation as an administrator. The issues described above no longer were there.

Conclusion: It probably is good to always run the OWM installation as an administrator. Others may not have problems with not doing so, but if such issues are going to occur, running installation as an administrator might prevent them.

Servus,