Read packet not supported on coin node, fatal error, game does not boot #77

Open icex2 opened 3 years ago

In GitLab by @penguin2233 on Apr 12, 2021, 16:42

Current behavior

Fatal error logged, program quits

Detailed Description

After launching, it will crash to desktop [2021/04/13 00:36:13] M:ezusb-emu-device: get_device_descriptor: vid 547, pid 2235 [2021/04/13 00:36:14] F:ezusb-iidx-emu-node-coin: Read packet not supported on coin node [2021/04/13 00:36:14] M:inject-debugger: EXCEPTION_DEBUG_EVENT(pid 3212, tid 2428): xEXCEPTION_BREAKPOINT 0x7C90120E

Bemanitools version(s) affected

v5.34, 3c7bf1f9e8f2640949b7a3fa46a9d6a2b75618e5

Game(s) and version(s) affected

IIDX11 and 12 (have not tried other games using iidxhook1)

Log output

logfile.log

Configuration files

iidxhook-12.conf iidxhook-11.conf

Command line arguments

gamestart-11.bat, gamestart-12.bat

OS version

Microsoft Windows XP Professional SP3

Hardware specs

CPU: i5-2400
RAM: 4 GB
GPU: Intel HD2000

In GitLab by @penguin2233 on Apr 12, 2021, 17:33

bool ezusb_iidx_emu_node_coin_read_packet( struct ezusb_iidx_msg_bulk_packet *pkg) { log_warning("cut"); return EZUSB_IIDX_COIN_CMD_STATUS_OK; }

This can boot the game, but it seems this code keeps running so maybe the game is keep sending read packets?

https://dev.s-ul.eu/djhackers/bemanitools/-/blob/master/src/main/ezusb-iidx-emu/node-coin.c

Not sure if this just fixes the symptom rather than the actual problem. It's been forever that I have looked at that part of the code. However, I remember that some "nodes" in the higher level protocol of the ezusb IO did not use the read and write calls. Therefore, I put that fatal log to catch any unexpected state if that ever happens.

I checked your log file, some notes:

You are running this inside a VM (VMWare)
OS is Windows XP SP3

I just ran this inside a Win 10 VM also on VMWare and this is what I would expect of the relevant part:

M:ezusb-emu-device: get_device_descriptor: vid 547, pid 2235
M:ezusb-emu-device: vendor req 00, value 0001, index 0100
M:ezusb-emu-device: vendor req: reset hold, starting fw download...
M:ezusb-emu-device: upload_fw: offset: 0043, nbytes: 0003
M:ezusb-emu-device: upload_fw: offset: 0023, nbytes: 0003
M:ezusb-emu-device: upload_fw: offset: 003b, nbytes: 0003
M:ezusb-emu-device: upload_fw: offset: 0000, nbytes: 0003
M:ezusb-emu-device: upload_fw: offset: 1ae5, nbytes: 004e
M:ezusb-emu-device: upload_fw: offset: 0003, nbytes: 0019
M:ezusb-emu-device: upload_fw: offset: 0046, nbytes: 0400
M:ezusb-emu-device: upload_fw: offset: 0446, nbytes: 03f3
M:ezusb-emu-device: upload_fw: offset: 0839, nbytes: 03f0
M:ezusb-emu-device: upload_fw: offset: 0c29, nbytes: 0400
M:ezusb-emu-device: upload_fw: offset: 1029, nbytes: 03e1
M:ezusb-emu-device: upload_fw: offset: 140a, nbytes: 03ec
M:ezusb-emu-device: upload_fw: offset: 17f6, nbytes: 0288
M:ezusb-emu-device: upload_fw: offset: 0026, nbytes: 0011
M:ezusb-emu-device: upload_fw: offset: 1a7e, nbytes: 0067
M:ezusb-emu-device: upload_fw: offset: 001c, nbytes: 0001
M:ezusb-emu-device: vendor req 00, value 0001, index 0000
M:ezusb-emu-device: vendor req: reset release, finished fw download
M:ezusb-emu-device: get_device_descriptor: vid 547, pid 2235
M:ezusb-iidx-emu-node-sec-mem: EZUSB_SECURITY_MEM_V1_CMD_WRITE
M:ezusb-iidx-emu-node-sec-mem: Writing security memory 0x00
M:ezusb-iidx-emu-node-sec-mem: Writing security memory 0x01
M:ezusb-iidx-emu-node-sec-mem: Writing security memory 0x02
M:ezusb-iidx-emu-node-sec-mem: Writing security memory 0x03
M:ezusb-iidx-emu-node-sec-mem: Writing security memory 0x04

Do you have another machine, either native or another VM, that you can test this on as well? I would like to verify if that is a Windows XP only issue.

In GitLab by @penguin2233 on Apr 14, 2021, 16:51

I'm not sure if it is an issue with my data, because I tried it in the VM (to make it easier to grab logs) and on 2 physical machines. They are all running XP SP3. I will try on other OS (10, 8.1).

In GitLab by @penguin2233 on Apr 15, 2021, 04:48

Windows 10 1909 has the same issue. I tried on another machine with 8.1 and XP SP3, the game was able to start on 8.1 but not on XP SP3.

10.log 8point1.log

Really odd. If you have the skills, can you check whether iidx 11 or 12 calls ReadFile and what it expects from the result returned? For a proper fix, we should implement a hook that behaves as expected by the game.

In GitLab by @penguin2233 on Apr 16, 2021, 11:16

I can try but I doubt I could get anywhere.

any update on this issue? can confirm it happens on windows 10

I don't have any updates on this since I haven't picked up the issue due to personal prioritization. I also cannot give you any ETA when I have the resources to pick this up. Anyone else is free to take a shot at this and propose changes in a PR.

ok

With the recent batch of fixes included in the following PR, this issue could now be fixed. Reading the backlog of this issue, it seems like it is related to the ezusb data race and buffer inconsistency problem in btools. Relevant PR: https://github.com/djhackersdev/bemanitools/pull/236

Changes are included in latest 5.44 release.

@Nbisbo Can you test with the latest 5.44 release and report back if this is still an issue?

still happening inject.log

removeing the e and f folders gets the game to boot but the game fails to save its backup data and saves the clock data to windows

I:iidxhook1: Build Mar  3 2018 17:32:13, gitrev 7296e7c9dfa68cf60f06cd8c97e3bd07229e5063

It appears you are using a very old build of iidxhook. Please upgrade to the latest and verify that you are using it by checking the logs.

here it is note that its not makeing a log file but I saved the comand line output log.txt

Its fixed used a different folder in install and that got it working. sorry for the iusses

Its fixed used a different folder in install and that got it working. sorry for the iusses

I am interested in how you fixed that issue for you. Can you explain how you had the game setup before when it didn't work, then explain what you changed to make it work? Maybe there is something we could add to the docs or another issue we don't see, yet.

there were different build folders in the dump I had I used the JAA(B) instead of the JADC folder.

As im not part of the site I use what I can get and sometimes its messy

there were different build folders in the dump I had I used the JAA(B) instead of the JADC folder. As im not part of the site I use what I can get and sometimes its messy

That sounds like one of those very old (dirty) dumps that include some very old tooling and patched binary files. That is known to cause issues. Do you have any folders just called JAA, JAB, JAC, etc.? The JAAC (with the additional C at the end) are the "dirty" ones. Afaik the fourth letter C means "cracked".

Also, I would consider this issue closed if you don't mind as it sounds to me that using non-clean data is the root cause of this.

djhackersdev / bemanitools