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
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](https://dev.s-ul.net/djhackers/bemanitools/uploads/5fcecd260699b55b5fe45d363ee635a6/logfile.log)
### Configuration files
[iidxhook-12.conf](https://dev.s-ul.net/djhackers/bemanitools/uploads/4d577b0cef333e049b60792db6992c25/iidxhook-12.conf)
[iidxhook-11.conf](https://dev.s-ul.net/djhackers/bemanitools/uploads/95adea9fa64ee40c79140f2c8ebea42d/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:
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.
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.
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 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](https://dev.s-ul.net/djhackers/bemanitools/uploads/34e88353386f58d845769308b79825c3/10.log)
[8point1.log](https://dev.s-ul.net/djhackers/bemanitools/uploads/aaba2c4cf263a454611cc1df3b09a189/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.
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.
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.
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.
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?
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?
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.
```
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
here it is note that its not makeing a log file but I saved the comand line output
[log.txt](https://github.com/djhackersdev/bemanitools/files/11782647/log.txt)
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.
> 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
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.
> 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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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 0x7C90120EBemanitools version(s) affected
v5.34,
3c7bf1f9e8Game(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
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:
I just ran this inside a Win 10 VM also on VMWare and this is what I would expect of the relevant part:
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
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
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
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.? TheJAAC(with the additionalCat the end) are the "dirty" ones. Afaik the fourth letterCmeans "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.