Wait really? I did not expect that information would be useful. I didn't click Show Details but I still have some information that got dumped into the terminal, maybe it is what you are looking for.
Incidentally I gave the glitch another try, but didn't do quite as well on my second attempt. I got 8 smelters and 11 structure factories down by the time I used up the kits. No crashes :)
Here's the stuff in the terminal:
wine: Unhandled page fault on write access to 0x00000000 at address 0x4582920 (thread 0009), starting debugger...
Unhandled exception: page fault on write access to 0x00000000 in 32-bit code (0x04582920).
Register dump:
CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
EIP:04582920 ESP:0033afc3 EBP:0033fcd0 EFLAGS:00010206( R- -- I - -P- )
EAX:00000000 EBX:00000018 ECX:1100cda3 EDX:000218a0
ESI:045828f8 EDI:04582934
Stack dump:
0x0033afc3: 00045700 3282e400 00000200 00000700
0x0033afd3: 0090ba00 00140000 00a20000 00000500
0x0033afe3: 00045800 32820400 00000200 00000700
0x0033aff3: 0098f800 00140000 00a44000 00000500
0x0033b003: 00045900 32812400 00000200 00000500
0x0033b013: 01693600 00140000 0084c000 00000f00
Backtrace:
=>0 0x04582920 (0x0033fcd0)
0x04582920: addb %al,0x0(%eax)
Modules:
Module Address Debug info Name (35 modules)
PE 360000- 3d0000 Deferred out2res
PE 400000- 5bc000 Deferred outpost2
PE 10000000-10011000 Deferred op2ext
PE 11000000-11013000 Export cps2
PE 7b420000-7b5d1000 Deferred kernel32
PE 7bc10000-7bc14000 Deferred ntdll
PE 7d150000-7d154000 Deferred dsound
PE 7d1d0000-7d1d3000 Deferred winealsa
PE 7d340000-7d348000 Deferred oleaut32
PE 7d580000-7d584000 Deferred mmdevapi
PE 7d7e0000-7d7e3000 Deferred msvcr120
PE 7d8c0000-7d8c4000 Deferred uxtheme
PE 7dc30000-7dc33000 Deferred concrt140
PE 7dc60000-7dc64000 Deferred winex11
PE 7df10000-7df13000 Deferred api-ms-win-crt-heap-l1-1-0
PE 7df30000-7df33000 Deferred api-ms-win-crt-stdio-l1-1-0
PE 7df40000-7df43000 Deferred api-ms-win-crt-string-l1-1-0
PE 7df50000-7df53000 Deferred api-ms-win-crt-runtime-l1-1-0
PE 7df70000-7df73000 Deferred vcruntime140
PE 7dfa0000-7dfa4000 Deferred ucrtbase
PE 7e0c0000-7e0c3000 Deferred msvcp140
PE 7e1b0000-7e1b4000 Deferred iphlpapi
PE 7e1e0000-7e1e4000 Deferred ws2_32
PE 7e210000-7e214000 Deferred wsock32
PE 7e230000-7e234000 Deferred imm32
PE 7e260000-7e263000 Deferred usp10
PE 7e2a0000-7e2f2000 Deferred comctl32
PE 7e3e0000-7e3e9000 Deferred msacm32
PE 7e410000-7e489000 Deferred winmm
PE 7e4d0000-7e4d4000 Deferred rpcrt4
PE 7e560000-7e588000 Deferred ole32
PE 7e6c0000-7e6c4000 Deferred advapi32
PE 7e730000-7e737000 Deferred gdi32
PE 7e870000-7e970000 Deferred user32
PE 7eff0000-7eff4000 Deferred version
Threads:
process tid prio (all id:s are in hex)
00000008 (D) Z:\home\user\games\outpost2\137\Outpost2.exe
0000007a 15
00000077 15
0000006b 0
0000006a 0
00000009 0 <==
0000000e services.exe
00000020 0
0000001b 0
00000013 0
00000010 0
0000000f 0
00000011 winedevice.exe
00000018 0
00000017 0
00000016 0
00000012 0
00000019 plugplay.exe
0000001d 0
0000001c 0
0000001a 0
0000001e winedevice.exe
00000022 0
00000021 0
0000001f 0
00000025 explorer.exe
00000031 0
0000002c 0
0000002b 0
00000026 0
System information:
Wine build: wine-4.4
Platform: i386 (WOW64)
Version: Windows 7
Host system: Linux
Host version: 4.20.4-gentoo
Hmm, the crash address doesn't appear to be from Outpost2.exe. In fact, it's not in any of the list PE modules. I suspect the crash might be coming from Wine itself.
The crash address is EIP:04582920, which is identified in the first line of the dump as ... at address 0x4582920.
The instruction at that address is (AT&T/GAS syntax):
0x04582920: addb %al,0x0(%eax)
In AT&T/GAS (Gnu As(sembler)) syntax, the source and destination operands are reversed from Intel syntax. GAS syntax uses OpCode Source, Destination. That means the instruction is trying to add the byte in the al register to the memory location in the eax register, offset by a constant of 0 bytes.
The eax register contains the value 0 (EAX:00000000 under Register dump). That would denote the nullptr value. Typically the OS reserves that section of the address space, and doesn't allow access to it, mostly as a way of detecting attempts to dereference a nullptr. As such, that address will not be valid when accessing the page tables, which results in the unhandled page fault that crashed the program.
There is insufficient stack dump or backtrace to determine a point of origin within Outpost2.exe. Hence I'm afraid I can't determine a root Outpost 2 cause from the posted information.