Closed die4teoffenbarung closed 4 years ago
Do you have to do something else other than launch the game twice? I can't reproduce the issue on Windows 10. Based on your logs, the main window received WM_CLOSE, indicating someone has closed it.
Do you have to do something else other than launch the game twice? I can't reproduce the issue on Windows 10. Based on your logs, the main window received WM_CLOSE, indicating someone has closed it.
It's a Online Game and often opened twice or more often for playing with different Characters "at the same time".
The problem seems to only exist on ATI-Graphics, NVidia Users don't seem to be affected by this.
I also have an AMD graphics card and I can run 2 instances on Windows 10 just fine. However, I have not logged in on either instances, that is why I asked if there are additional steps (like logging into the game world) that may be relevant to reproduce the crash.
I'm also a bit confused because in your first post you mention that this problem affects Windows 10, but the logs you linked are from Windows 7. It also seems to show a scenario where the game was successfully launched, the user chose to exit the game and it only seems to have crashed after that. (Which is still a crash that should be fixed, but it doesn't seem to be related to the original problem.)
Also, just to be sure: the game is "The 4th Coming" from t4c.com, right?
I also have an AMD graphics card and I can run 2 instances on Windows 10 just fine. However, I have not logged in on either instances, that is why I asked if there are additional steps (like logging into the game world) that may be relevant to reproduce the crash.
I'm also a bit confused because in your first post you mention that this problem affects Windows 10, but the logs you linked are from Windows 7. It also seems to show a scenario where the game was successfully launched, the user chose to exit the game and it only seems to have crashed after that. (Which is still a crash that should be fixed, but it doesn't seem to be related to the original problem.)
I'm sorry, you are totaly right, i just mixed up some things. It was of course Windows 7 in this case and is freezing the first window opened if opening for example the Character sheet. (I try to fetch the right debug.log and getting back to you with more informations, I'm at work for the moment and can't test.)
At Windows 10 it's a similar problem but at the moment the guy is not available, so can't get more informations about this.
Also, just to be sure: the game is "The 4th Coming" from t4c.com, right?
An older fork, yes, www.d4o.info
Thanks for your time and best regards!
Be careful about uploading debug logs as they can contain sensitive information. Whatever text is displayed on the screen may be visible also in the debug logs, including the user ID on the login screen. More importantly, don't type in sensitive information like passwords, as they could likely be reconstructed from the logs as well. The log you have sent seems to have used a saved password, which should be safe, so keep using that method while collecting debug logs.
Thanks for the heads up, im aware of it.
The first instance is freezing and i cant move after starting a second window, if i try to move in the first one it gets a "white" overlay and hangs up, need to close with X-Button. The second window is use able like it should. So i hope it's more helpful this time. :) ddrawa.zip
That sounds like the first instance has ran into a deadlock. If the logs are from that, it's not obvious to me how that happened. Can you reproduce it without logging into the game? Just stay on the login screen and then launch the second instance.
I'd ask for a crash dump but I'm not sure how safe that is for your password. Probably not a good idea unless you can use a dummy account/password that you don't mind getting compromised. If you can do that, then find the first (deadlocked) process in Task Manager, then right click on it and choose "Create dump file". You could also try "Analyse wait chain" before that and see if it outputs anything useful.
Also, you have some surfaces lost in the logs before the crash/deadlock, which is unusual for a windowed application. This should only happen in case of a display mode change or a driver crash. Do you have some compatibility settings applied to the executable, or did you change some desktop settings or display modes manually?
That sounds like the first instance has ran into a deadlock. If the logs are from that, it's not obvious to me how that happened. Can you reproduce it without logging into the game? Just stay on the login screen and then launch the second instance.
Yes, same behavior.
I'd ask for a crash dump but I'm not sure how safe that is for your password. Probably not a good idea unless you can use a dummy account/password that you don't mind getting compromised. If you can do that, then find the first (deadlocked) process in Task Manager, then right click on it and choose "Create dump file". You could also try "Analyse wait chain" before that and see if it outputs anything useful.
I'll get you one as fast as i get back at home. :)
Also, you have some surfaces lost in the logs before the crash/deadlock, which is unusual for a windowed application. This should only happen in case of a display mode change or a driver crash. Do you have some compatibility settings applied to the executable, or did you change some desktop settings or display modes manually?
Only "Run as admin", all others default/disabled.
At this commit https://github.com/narzoul/DDrawCompat/commit/55e08f62d4a1a1671fa61f78134384cbbc6e42ce it was working fine and starts without problems in 2 instances. Don't know if this helps in any way.
I'd ask for a crash dump but I'm not sure how safe that is for your password. Probably not a good idea unless you can use a dummy account/password that you don't mind getting compromised. If you can do that, then find the first (deadlocked) process in Task Manager, then right click on it and choose "Create dump file". You could also try "Analyse wait chain" before that and see if it outputs anything useful.
It's weird, build the last release by my self and now it works again.
I'll close this issue in near future after do some more tests. So far thanks for your time & help! :)
Hi, the problem seems to persist for some players. here is the log + dump + pdb https://drive.google.com/file/d/1NVvzFzfJ2k1-ezvZtNEDkd2J8F_G_mKE/view?usp=sharing
Best regards
Could you attach the ddraw.dll file as well? The debugger is asking for it, but not accepting any of my builds.
Also, where do I get t4c client.exe? My game folder has no such file. The crash seems to originate from it, not from DDrawCompat.
I hope this will help :)
That looks like the Release build. Since you also attached debug logs, the right version would have to be either the ReleaseWithDebugLogs or Debug build. Though it might not help anyway because I still can't see any relationship between the crash and ddraw.
DDrawDebug.zip my bad, but i guess it wont help then...
Thats somehow weird, without ddraw.dll it's working fine for them, beside performance.
A bigger Dump wouldn't help either, right?
No, I don't think it would.
Is this still the issue with 2 instances of the game running? Would it be possible to reproduce it by running the 2 instances from 2 separate directories to make sure the logs don't conflict?
In the logs attached, I can still only see the main window receiving WM_CLOSE as if someone closed it, and then based on the crash dump it crashes on some error (invalid critical section?) in t4c client.exe (apparently unrelated to ddraw). I'm wondering if the logs are from the correct instance.
Meanwhile I tried reproducing the issue myself too, but I only got as far as trying to login from a second account, which doesn't work (player not known or suspended or some such). And with just staying on the login screen with the second instance, the first instance doesn't crash, even when opening the character sheet.
Nevermind, I did manage to log in with both accounts now, but it still doesn't crash. I had the character sheet open in both instances. What else needs to be done?
It should be enough to open a second instance. I'll write one of them right now and ask for debug from 2 different folders and then i sent you both. It's really hard if you ask people for logs and they don't have a clue what they're doing.
Thanks so far! :)
So, it seems like it was a permission problem for one of them. After running as Admin the problem seems to be gone. Is this in any way plausible? I think it makes sense, a lot. (Nevermind they should run as admin any way...)
Thanks so far, I'll close this as soon i could test if this fix the issue for all.
It doesn't really explain why it works without DDrawCompat, but if it fixes the issue, it's good enough for me. :P
Since last 1 or 2 Commits i got this problem on Windows 10. Before it was all working fine. ddraw.log