• We have updated our Community Code of Conduct. Please read through the new rules for the forum that are an integral part of Paradox Interactive’s User Agreement.

adfs

Captain
11 Badges
Sep 20, 2009
489
57
  • Arsenal of Democracy
  • Crusader Kings II
  • Europa Universalis IV
  • Hearts of Iron IV: Cadet
  • Hearts of Iron IV: Death or Dishonor
  • Hearts of Iron IV: Expansion Pass
  • Darkest Hour
  • Deus Vult
  • Europa Universalis III: Chronicles
  • For The Glory
  • 500k Club
ver: 1.1
mode: multiplayer (both start scenario and load save game)

description:
after connection screen, the gameplay screen won't show up, get a CTD
(application error: ftg.exe module: ddraw.dll address:0x00032c85)

seems randomly, because not happen every time. both start scenario and load save game may meet this bug.

noted that if in the connection screen, the "player status" become "ok", this bug won't happen.

every CTD when the "player status" still is "connecting".

sorry for my poor engilsh, thx for your attention.
 
Upvote 0
Thanks for reporting.
 
Going from your comments in the 1.2 release thread, I guess this is still present?

Are you using a mod? Is this LAN or internet? Is Logs\traffic.csv generated (in the vanilla Logs directory)?
 
good news

1st post is in vanilla mode MP(multiplayer).

these days i have tried some AGCEEP MP games, but i got this CTD every time. whatever 1.1 or 1.2.
after some testing, i found that if shields=enhanced(game settings), will get this CTD every time in AGCEEP MP.
if shields=classic, won't CTD.

maybe this type of CTD caused by shields=enhanced? especially in AGCEEP MP games?
 
That is odd; I don't see why the shields could cause such a crash. Are both installs identical? Can both play single-player AGCEEP with enhanced shields?
 
yes. both installs identical. i have tried install on a, copy to b, and install both on a b.

both can play AGCEEP SP games with enhanced shields.

and i have tried with lan/internet connection type and local/internet game mode, they are all same result.


i don't know why AGCEEP+enhanced shileds will get this CTD EVERY time in MP, but vanilla not everytime, just some times.

traffic.csv was not generated .

whatever 1.1/1.2, vanilla/AGCEEP, this CTD always is application error: ftg.exe module: ddraw.dll address:0x00032c85

i was used different directx and vc++ runtime, no help, same result.
 
sorry...

after some successfully testing, now i meet this CTD with classic shields again...

this problem back to chaos...:wacko:
 
Is it the host or the client or both that crash? And does it only happen at load time, not while the game is running?
 
both host and client

host ctd first, client second.

both is application error: ftg.exe module: ddraw.dll address:0x00032c85

only happen at load time, both start scenario and load save game
 
Just asking, are you loading ingame or not?
 
not entering the gameplay screen.

after connection screen, the gameplay screen won't show up, get this CTD
 
these days i made some testing. (lan computers, A and B)
use ftg 1.2 vanilla and local area mode. 10+ times for each test.

clean reinstall 2 computers' os(xp sp3 msdn), after install finished, do not do any configuration to os, only install hardware drivers and also without configuration.

this is for keep clean and avoid any other things to affect ftg running.

tested with default directx with os, newest directx, vc2005 sp1, vc2008sp1, old hardware drivers, newest hardware drivers. (any changes made on clean os, becoz i used Ghost)

still get this CTD. (about 6-8ctd/10times)
but after testing, seems this ctd is not affect by os/drivers/software




then i go to find more computers to test. C/D/E joined.

a<->b (as i said. about 6-8ctd/10times)
a<->c (6ctd/10times)
a<->d (1ctd/11times)
a<->e (6ctd/34times)

b<->c (0ctd/10times)

don't know why different computer have such big different result. up to which 2 computers to connect. :confused:

a: amd 3600+, ati hd3850, mem2g
b: dell1501 laptop, sempron 3500+, ati x1150, mem1g
c: sony vaio w117 laptop, atom 1.66g, gma950, mem1g
d: p4 3.0, geforce6200, mem768m
e: celeron2.4, gma900 or 950, mem512m
 
Last edited:
i found a thread, maybe same situation.
http://forum.paradoxplaza.com/forum/showpost.php?p=10636518&postcount=21

in the connection screen:
player1(host) status: ok
player2(client) status: connecting

if player2 status will become ok in a short time, won't CTD, entering gameplay screen successfully

if player status keep "connecting" longer time, will not become ok, the CTD surely happen.


in a few words:
other players status
connecting->ok->no CTD
connecting->still connecting->CTD

i am sure it's not network problem, i use cmd->ping -t , never has package lost.
 
I'm still (slowly) trying to reproduce this. If I can't get it to crash on my configuration, it's hard to diagnose.
 
though shields=classic can't totally avoid this CTD, it's largely avoid this ctd.

odd.
 
We are getting this issue too, for some of us. Some are getting in, but with some configuration of people, we are crashing with this very issue.

The game seems to be broken somehow.

We are playing with BurningEGO's UMP mod. The error is ddraw.dll at some point, perhaps after some timeout waiting for some people to join? We saw no pattern. As most, we managed to get 7 people to join. It would seem only some configurations were broken, but as I said, no pattern.
 
Now me and two others did some extensive testing. I could host and get into the game with both of them, one at a time. But when both were in the game at the same time, at least one of us would always crash

And this even without the ddraw error. It would just be a direct crash to desktop, no questions asked.

We ran via hamachi (virtual LAN), they had windows 7 in compatibility mode for win XP service pack 3, my OP.
 
I can for the record add that I didn't crash at all during any of this. I did however crash if I just let the game sit in the connecting screen for a couple of minutes when the host or someone else had a CTD. I'm not surprised that the app crash happened though considering nothing was going to happen.