I am getting a disk read error while trying to launch into this game from the menus.
Menus work fine, but loading into engine or intro movie seems to yield an error.
Please add more details, like log files. Also, make sure you're using a clean dump and avoid making any modifications
-Launch game via start new game option. (disk read error)
KrnlDebug.txt
CxbxDebug.txt
-Launch game via run tutorial option freeze.
KrnlDebug.txt
CxbxDebug.txt
@ergo720 Two lines jump out of this KrnlDebug.txt log :
WARN: KRNL: MmQueryStatistics with unusual size -> 0xAD574AF4
WARN: PMEM Out of physical memory!
Meaning this might have nothing to do with the NtReadFile failures (or it's running a corrupt dump).
@Crimsom13 can you please re-upload a new kernel log with the most-recent cxbx version? It now also prints if the xbe is valid, so we can rule out a corrupt dump. @PatrickvL a title that crashes with PMEM Out of physical memory! usually means the game is not expecting the allocation to fail, and it will attempt to dereference the pointer returned by the memory function (nullptr in the case of failure), hence the crash. This title is not crashing it seems though, so it could be something else (or it's detecting the nullptr and displaying the error screen instead). I have also seen the MmQueryStatistics error in other games, but never investigated the cause of it. They could have the same cause, so I'll try to reproduce again the error (if it still happens).
We might need an actual pool allocator in the ExAllocatePool and ExAllocatePoolWithTag API's as these currently use whole pages, using more memory than the original kernel that has a pool, which could explain why out of memory is reached earlier than in an original kernel.
See https://github.com/Cxbx-Reloaded/Cxbx-Reloaded/issues/953
PS: The homebrew game called "X-Marbles" reserves all available memory until it hits out-of-memory conditions too. That might be a totally different use-case then what we have here, but I guess there's no harm in mentioning this as a reminder, right?
looks like it's getting an invalid signature.
[0x34B0] WARN: Invalid xbe signature. Homebrew, tampered or pirated xbe?
Think I fixed my rip, still getting disk read error, here is the latest log file.
Single player start game (disk read error)
CxbxDebug.txt
KrnlDebug.txt
Start training mode (hard lock up)
CxbxDebug.txt
KrnlDebug.txt
Update: X-Marbles doesn't hit an "out of memory" error even on the current master at the moment (a6efd010), so it's unrelated to ExAllocatePoolWithTag since it is still not implemented correctly in master (or I have a different version of X-Marbles).
KrnlDebug.txt
According to a discord post, @Crimsom13 encountered the same "Dirty disc error" with JSRF
[0x2614] WARN: PMEM Out of physical memory!
Org:"Z:\Media\Cache\JSRF_FATAL.ERR"
New:"$CxbxPath\Partition4\Media\Cache\JSRF_FATAL.ERR"
[0x0C20] MAIN: Terminating Process
but it turned out it was the same timing error which afflicts DOA titles as well. If so, then the above error could have the same origin and be unrelated to memory errors. @Crimsom13 can you retest the game now that the pool manager is in, please?
the dirty disk error with JSRF was in 720p hack version which may have slowed the rendered down to the point it errored out? I tried it again in 420P and got though the intro just fine...
-Launch single player campaign (dirty disk error)
CxbxDebug.txt
KrnlDebug.txt
-Launch training (crash half way through load)
CxbxDebug.txt
KrnlDebug.txt
same - progress on conflict vietnam though see thread for details.
This is a game specific issue an should be in our game-compatibility tracker instead.
Most helpful comment
We might need an actual pool allocator in the
ExAllocatePoolandExAllocatePoolWithTagAPI's as these currently use whole pages, using more memory than the original kernel that has a pool, which could explain why out of memory is reached earlier than in an original kernel.See https://github.com/Cxbx-Reloaded/Cxbx-Reloaded/issues/953
PS: The homebrew game called "X-Marbles" reserves all available memory until it hits out-of-memory conditions too. That might be a totally different use-case then what we have here, but I guess there's no harm in mentioning this as a reminder, right?