Closed hilts-vaughan closed 2 years ago
I tried capturing one via the wrappers DLL from the wiki but no trace file was outputted. Is it supposed to be in the game dir?
No, apitrace will create the trace file in the wine prefix under drive_c/users/$USER/Desktop
.
Can someone make an apitrace with WineD3D?
The ones @hilts-vaughan made are just 2KB and just finish without any hitch (and also don't draw anything).
I'm happy to retake the trace if I can figure out why it's so small. The game is also free (the classic edition at least, which has the same problem) if anyone wants to tackle it again.
Do you want me to try taking the trace with WineD3D enabled and DXVK disabled to be clear?
On Sun., Nov. 14, 2021, 1:01 p.m. Robin Kertels, @.***> wrote:
Can someone make an apitrace with WineD3D? The ones @hilts-vaughan https://github.com/hilts-vaughan made are just 2KB so they are almost certainly useless.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/doitsujin/dxvk/issues/2363#issuecomment-968337552, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIHPJ3G2BDM6JKLN6Q32RLUL72QBANCNFSM5H7LHMOQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
Do you want me to try taking the trace with WineD3D enabled and DXVK disabled to be clear?
Yes, exactly that.
I tried it myself but I can't get Pico Park Classic to run at all. It doesn't work with DXVK and it doesnt work with WineD3D either. So this is most likely a Wine issue, rather than a DXVK one.
You have to edit userdata.lua
to have full screen set to 0 or it crashes immediately and you have to use PROTON_USE_WINED3D11=1 %command%
as the launch command. The game runs on D3D9 though I think since the log from the non-classic version has this:
pico_park_d3d9.log
info: Game: pico_park.exe
info: DXVK: v1.9.2
info: Built-in extension providers:
info: Win32 WSI
info: OpenVR
info: OpenXR
warn: OpenXR: Unable to get required Vulkan instance extensions size
info: Enabled instance extensions:
info: VK_KHR_get_surface_capabilities2
info: VK_KHR_surface
info: VK_KHR_win32_surface
warn: OpenXR: Unable to get required Vulkan Device extensions size
info: D3D9: VK_FORMAT_D16_UNORM_S8_UINT -> VK_FORMAT_D24_UNORM_S8_UINT
info: NVIDIA GeForce GTX 1080:
info: Driver: 495.44.0
info: Vulkan: 1.2.186
info: Memory Heap[0]:
info: Size: 8192 MiB
info: Flags: 0x1
info: Memory Type[7]: Property Flags = 0x1
info: Memory Heap[1]:
info: Size: 24036 MiB
info: Flags: 0x0
info: Memory Type[0]: Property Flags = 0x0
info: Memory Type[1]: Property Flags = 0x0
info: Memory Type[2]: Property Flags = 0x0
info: Memory Type[3]: Property Flags = 0x0
info: Memory Type[4]: Property Flags = 0x0
info: Memory Type[5]: Property Flags = 0x0
info: Memory Type[6]: Property Flags = 0x0
info: Memory Type[8]: Property Flags = 0x6
info: Memory Type[9]: Property Flags = 0xe
info: Memory Heap[2]:
info: Size: 246 MiB
info: Flags: 0x1
info: Memory Type[10]: Property Flags = 0x7
info: Process set as DPI aware
If using PROTON_USE_WINED3D9
(is this flag valid still?), then the game crashes like it does with DXVK.
It seems like PROTON_USE_WINED3D
also will have the same black screen:
However, to be clear, when running with DXVK only, the game will just simply crash.
I need either a WineD3D or a Windows apitrace to look into this.
I can take a Windows one for you. Let me boot into Windows to grab it for you.
I've provided a PICO Park: Classic Windows API trace in the same folder. I will try and grab one from the full game as well.
The windows apitrace works just fine. That's usually a strong sign that this is a Wine problem rather than a DXVK one.
You could try running the game with DXVK on Windows (without apitrace) to confirm that. (Just grab the 32bit d3d9.dll and put that next to the games exe).
The game hangs with a frozen black screen and then crashes just like Linux under Windows when using the 32 bit DXVK DLL on PICO PARK: Classic. I can provide more logs if you think this is something that might be in DXVK or if you think it's a WINE bug that DXVK is tripping, we can explore that too (perhaps upstream)
The game hangs with a frozen black screen and then crashes just like Linux under Windows when using the 32 bit DXVK DLL.
Probably not a Wine bug after all then.
Cool, I tried the first release of d9vk-0.10.tar.gz
from way back when and it has the same problem as well. Are there any other logs you need that would be useful from Windows etc?
Same thing; black screen and then crashes.
I've also unpacked the game with Steamless and included a crash dump (available on Google Drive):
(3a00.650): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000000 ebx=00000001 ecx=03fef91c edx=03fef95c esi=0400a110 edi=03fef91c
eip=00c0f1a7 esp=016ff74c ebp=016ff758 iopl=0 nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202
pico_park_dx9+0x9f1a7:
00c0f1a7 8b08 mov ecx,dword ptr [eax] ds:002b:00000000=????????
I'll leave it with you folks now; please let me know if there is anything I can do to help. :)
Some other notes from attempting to grok what is happening in Ghidra and WinDbg for my own curiosity:
The Linux log had this line 77244.140:010c:0110:err:system:EnumDisplaySettingsExW Invalid device name L"".
, which seemed kind of suspicious. I used a breakpoint to find all syscalls to enumerate Windows using bp User32!EnumDisplaySettingsExW
and printing out arguments (such as the first value being passed in) .printf "Finding device: <%mu>", dwo(@esp+4);
, though I
just got back the default display on Windows: Finding device: <\\.\DISPLAY1>0:000>
. I'm not sure how to debug the syscalls in Linux, so I can't verify, though the logs seem to imply that it's a blank string or something. Maybe that's an issue but since it's closing and crashing on Windows as well, perhaps there is an issue here. Or maybe it's different issues. :')
On Windows, without DXVK, the function is never called. With DXVK, the stack looks like this with some stub I don't understand:
I don't understand how that stub works to know how that param EnumDisplaySettingsExW
(lpszDeviceName
) is sourced, so I can't tell for sure how that happened. I'm guessing some other syscall. It looks like some pointer is sourced and injected in from the ASM from what I can tell:
All that being said, running under Linux and WINE we can see that it failed but for the most part it's scanning the rest fine:
0110:trace:system:EnumDisplaySettingsExW device:L"\\\\.\\DISPLAY1" mode index:0xffffffff position:(0,0) resolution:2560x1440 frequency:75Hz depth:32bits orientation:0.
0110:trace:system:EnumDisplaySettingsExW (null) 0xffffffff 011BE234 0
0110:trace:system:EnumDisplayDevicesW (null) 0 011BDC58 0
0110:trace:system:EnumDisplaySettingsExW device:L"\\\\.\\DISPLAY1" mode index:0xffffffff position:(0,0) resolution:2560x1440 frequency:75Hz depth:32bits orientation:0.
0110:trace:system:EnumDisplaySettingsExW (null) 0xffffffff 011BE674 0
0110:trace:system:EnumDisplayDevicesW (null) 0 011BE098 0
0110:trace:system:EnumDisplaySettingsExW device:L"\\\\.\\DISPLAY1" mode index:0xffffffff position:(0,0) resolution:2560x1440 frequency:75Hz depth:32bits orientation:0.
0110:trace:system:EnumDisplaySettingsExW (null) 0xffffffff 011BE814 0
0110:trace:system:EnumDisplayDevicesW (null) 0 011BE238 0
0110:trace:system:EnumDisplaySettingsExW device:L"\\\\.\\DISPLAY1" mode index:0xffffffff position:(0,0) resolution:2560x1440 frequency:75Hz depth:32bits orientation:0.
0110:trace:system:EnumDisplaySettingsExW (null) 0xffffffff 011BE814 0
0110:trace:system:EnumDisplayDevicesW (null) 0 011BE238 0
0110:trace:system:EnumDisplaySettingsExW device:L"\\\\.\\DISPLAY1" mode index:0xffffffff position:(0,0) resolution:2560x1440 frequency:75Hz depth:32bits orientation:0.
0110:trace:system:EnumDisplaySettingsExW (null) 0xffffffff 011BE814 0
0110:trace:system:EnumDisplayDevicesW (null) 0 011BE238 0
0110:trace:system:EnumDisplaySettingsExW device:L"\\\\.\\DISPLAY1" mode index:0xffffffff position:(0,0) resolution:2560x1440 frequency:75Hz depth:32bits orientation:0.
0110:trace:system:EnumDisplayDevicesW (null) 0 011BF7F8 0
0110:trace:system:EnumDisplayDevicesW (null) 1 011BF7F8 0
0110:trace:system:EnumDisplayDevicesW (null) 0 011BF7F8 0
0110:trace:system:EnumDisplaySettingsExW L"\\\\.\\DISPLAY1" 0xffffffff 011BFA34 0
0110:trace:system:EnumDisplaySettingsExW device:L"\\\\.\\DISPLAY1" mode index:0xffffffff position:(0,0) resolution:2560x1440 frequency:75Hz depth:32bits orientation:0.
0110:trace:system:EnumDisplayDevicesW (null) 1 011BF7F8 0
0110:trace:system:EnumDisplaySettingsExW L"" 0xffffffff 011BFA34 0
0110:err:system:EnumDisplaySettingsExW Invalid device name L"".
0110:trace:system:EnumDisplaySettingsExW (null) 0xffffffff 011BF774 0
0110:trace:system:EnumDisplayDevicesW (null) 0 011BF198 0
0110:trace:system:EnumDisplaySettingsExW device:L"\\\\.\\DISPLAY1" mode index:0xffffffff position:(0,0) resolution:2560x1440 frequency:75Hz depth:32bits orientation:0.
0110:trace:system:EnumDisplaySettingsExW (null) 0xffffffff 011BF774 0
0110:trace:system:EnumDisplayDevicesW (null) 0 011BF198 0
0110:trace:system:EnumDisplaySettingsExW device:L"\\\\.\\DISPLAY1" mode index:0xffffffff position:(0,0) resolution:2560x1440 frequency:75Hz depth:32bits orientation:0.
0110:trace:system:EnumDisplaySettingsExW (null) 0xffffffff 011BF154 0
0110:trace:system:EnumDisplayDevicesW (null) 0 011BEB78 0
0110:trace:system:EnumDisplaySettingsExW device:L"\\\\.\\DISPLAY1" mode index:0xffffffff position:(0,0) resolution:2560x1440 frequency:75Hz depth:32bits orientation:0.
0110:trace:system:EnumDisplaySettingsExW (null) 0xffffffff 011BF594 0
0110:trace:system:EnumDisplayDevicesW (null) 0 011BEFB8 0
0110:trace:system:EnumDisplaySettingsExW device:L"\\\\.\\DISPLAY1" mode index:0xffffffff position:(0,0) resolution:2560x1440 frequency:75Hz depth:32bits orientation:0.
0110:trace:system:EnumDisplaySettingsExW (null) 0xffffffff 011BF5F4 0
0110:trace:system:EnumDisplayDevicesW (null) 0 011BF018 0
0110:trace:system:EnumDisplaySettingsExW device:L"\\\\.\\DISPLAY1" mode index:0xffffffff position:(0,0) resolution:2560x1440 frequency:75Hz depth:32bits orientation:0.
0110:trace:system:EnumDisplaySettingsExW (null) 0xffffffff 011BEFD4 0
0110:trace:system:EnumDisplayDevicesW (null) 0 011BE9F8 0
0110:trace:system:EnumDisplaySettingsExW device:L"\\\\.\\DISPLAY1" mode index:0xffffffff position:(0,0) resolution:2560x1440 frequency:75Hz depth:32bits orientation:0.
0110:trace:system:EnumDisplaySettingsExW (null) 0xffffffff 011BF414 0
0110:trace:system:EnumDisplayDevicesW (null) 0 011BEE38 0
0110:trace:system:EnumDisplaySettingsExW device:L"\\\\.\\DISPLAY1" mode index:0xffffffff position:(0,0) resolution:2560x1440 frequency:75Hz depth:32bits orientation:0.
I suppose that the invalid display name is a red herring.
I may try and debug later to try and find more info for fun and learning (I come from a web. dev background), but if someone has insights in the meantime I would love to learn and understand how the solution comes together!
Any news on this?
Nothing from me. If you have a Windows partition, it may be valuable to try and see if it crashes for you under WIndows as well.
I don't have a Windows on hand, I think I can't help here.
Sadly i haven't been able to provide much help. I can reproduce that it shuts down instantly on linux with both wined3d and dxvk. And on windows the same with dxvk. But when i replay a short trace i made on windows it plays fine with dxvk as K0bin said. Haven't found any dxvk config options on linux that made it run, nor master or older versions.
tfo on Discord found out that this can be fixed by accepting D3DFMT_UNKNOWN in IDirect3D9::CheckDeviceType because it's allowed for windowed mode.
I don't see a PR. Do you need someone to test / implement it?
On Mon, Jun 27, 2022, 3:51 PM Robin Kertels @.***> wrote:
tfo on Discord found out that this can be fixed by accepting D3DFMT_UNKNOWN in IDirect3D9::CheckDeviceType because it's allowed for windowed mode.
— Reply to this email directly, view it on GitHub https://github.com/doitsujin/dxvk/issues/2363#issuecomment-1167814022, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIHPJ73ZI7YWZHGYND2XDTVRIA43ANCNFSM5H7LHMOQ . You are receiving this because you were mentioned.Message ID: @.***>
The person in discord who found the issue haven't responded back yet.
Should be fixed.
PICO Park will open with a black screen and then close in ~1 second on my machine (all machines?). This is well documented on Proton DB. I did some fishign around and found this thread with the developer engaging about it: https://steamcommunity.com/app/1509960/discussions/0/3046108212585124835/?ctp=4
It seems like they think shaders won't compile in DXVK properly, though that obviously is not the case. However, they do seem to think it's something to do with the graphics. If you run it with Wine D3D and let it run, you can hear audio and the game is "running" but it has a black screen (though it does not crash like it does when running under DXVK)
You can find some other information on the Proton GitHub as well: https://github.com/ValveSoftware/Proton/issues/5022
Software information
Name: PICO PARK (or PICO Park classic which is free and a small download to try out)
System information
Apitrace file(s)
Log files
Proton debug log: