Dragon Age: Origins Forum

Hi

We need to test out the newest patch.

I have installed it a few times with these combinations:

Physx
(old) C4p file - installs Dragon Age
and the patch 1.04

--

Physx
Dragon Age
patch 1.04

--

Dragon Age
patch 1.04

--

New winxpXP bottle
.net 3
DirectX Modern
Visual C ++ 2005
Visual C ++ 2008
MS XML 3
MS XML 6 ---- A lower version of this product has been detached on your system. Would you like to upgrade your existing installation? Yes.
physX - downloaded from the Nvidia site http://www.nvidia.com/object/physx-9.10.0224-driver.html
and installed.

Inserted the Dragon Age DVD and used (the old) C4P to install the game.

This works fine with version 1.0 of Dragon Age. Even the video and audio configure screen works. There one can turn on the sound, and make other adjustments before starting the game.

But with installing the patch 1.04 I received a Visual C ++ Runtime Library error. So that was a no go.

--

It seemed they all worked alright (except the last one). But with the same usual problems, no sound, and keep graphics on low or else it might crash/lag.

Has anyone found a better way of installing the patch?

Hi,

If you're interested in creating a debuglog, I'd be interested in
looking at why the c++ runtime error is being thrown -- let me know
if you're interested and I'll give you some more details..

Cheers!

Hi Don

Yes, I am very interested! It would be nice to figure out why the error happens.

Have a great day!

Hi Paal,

Okidoki....I'll give you some background of what I think I know about
this error being thrown -- which error are you seeing btw?...R6024?
To be sure, there's a number of different scenarios here...one end of
the scale I think is where the app provides it's own installation of
vcrun c++ redist (or one or another version ships with it) and some
versions ...I believe...are more tenuously linked back to the intrinsic
.NET install present...and this can all fly apart because at present,
in crossover/wine we do not have the full .NET support included...yet...
...in the end it might boil down to "Gee, I wish .NET 2.0 SP 1 & 2 worked"
..because that's what being called for - some part of the .NET subset....

...this, would be one of the goals of crossover/wine as a whole if you
think about it...ie; when the app/game advertising says 'minimum requirements
are winXP' or such, what that actually infers is winxp with all the
latest M$ updates and hotfixes...and you guessed it, they also assume all
variants of the .NET framework are all present and accounted for and
working as expected -- of course, an winxp bottle or wine_env is nowhere
near that...yet....but that's the golf course here. Sometimes, via library
overrides, you can work things past the c++ error and end up at the actual
culprit -- a .NET error message window popup asking you if you want to
send an error report back to M$ ...me thinks the error message says ".NET
2.0 SP1 required" ...it's plaintext ascii hidden in a 2mb file...(haha)...

The other biscuit here is the Physx install - it's crumbly at best and known
not to work...it will install via C4P etc and register itself so the app
itself is happy things are inplace - that doesn't mean that when the game.exe
asks for a certain Physx based function, that function is going to work - it
probably won't....you can imagine something like this is bound to happen in
all eventuality with 'currently active/popular/onwardsly maintained and patched
or updated apps/games', in as much as a response to these new hardware/software
technologies appearing ...one day, to remain 'current' or achieve extra features,
they also draw on library routines/functions outside the scope of what's currently
supported in crossover/wine...and then BLAMMO!...c++ runtime error...

Have a look at the following page;

http://www.codeweavers.com/support/wiki/SubmitTechSupportLog

That's pretty straight forward, but we probably want to look at a few more channels,
seeing as you say there's sound issues as well. In the 'extra logging channels'
area, tick the +seh & +thread boxes. Below that, in the 'Other" stringbox put
+ntdll,+loaddll,+dsound ...and then proceed to run the game and create the
debuglog. Make sure you gzip/zip the logfile created, make sure it has a meaningful
name, and upload it here - use the password TgdL47vUgd to login and upload the
debuglog -- that will give me a better picture of what's happening. If you want to
do 2 debug runs...ie; one before the patch breaks thing and one of the patch going
feral, do that too - the comparative view might be interesting...

Cheers!

Hello Don

Thank you for the very informative post!
I have not had a chance yet to reinstall. I'll let you know when I do!

About the sound issue:
In general Dragon Age (pc version run through Crossover Games on the Mac) has started with the disable sound active (sound is off).
One needs to enter into the settings.ini and turn on the sound OR
open the configure dialog box and choose audio (before pressing the play button which enters into the game). From there one can switch off the disable sound checkmark.
Usually the configure box comes up blank for video and audio, but it works with the install procedure I mentioned above for 1.0.

Thanks again Don. I look forward to testing this out and hopefully getting this install procedure to work with the patch.

I installed Dragon Age with the one version that works the best for me. Mentioned above.

Saved the after install log files, version 1.0 and 1.04
Created a debug file for 1.0
Created a debug file for 1.0 after having turned on sound (through the audio configure dialog box) and added a Direct3D key to wine in the regedit.
Created a debug file after having installed patch version 1.04.

The error I receive with the patch is Visual C++ Runtime Library error
R6034.

These files and a more detailed file of my progress are included in the debug report I uploaded.

Have a great day!

Hi Paal,

     Thanks for the logs....most informative.

I can see what's happening, I'm not sure if there's a clean resolve
to this yet -- it may very well be related to us -not- having the
.NET 2.0 SP1 & SP2 runtime supports...yet...but I can describe to you
what I'm seeing with the R6024 error...

fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.VC80.CRT" (8.0.50727.762)

Now...that's from debugDAver104.cxlog....what it tried to do there is
load a framework assembly that should've been created by .NET 2.0
(50727) against the Microsoft Visual C++ 2005 SP1 Redistributable (762).

There was a previous VC runtime redist that was subsequently replaced by
the Microsoft Visual C++ 2005 SP1 Redistributable package.

That assembly is never called for directly in debugDAver1.cxlog..the
loading is accomplished by the framework manifest entries. When I look
at that in debugDAver1.cxlog, I see something like..

name=L"\??\C:\windows\winsxs\manifests\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.4053_x-ww_e6967989.manifest"

Conversely (in debugDAver104.cxlog) it's trying to do this instead;

name=L"\??\C:\windows\winsxs\manifests\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_0de06acd.manifest"

It would appear as though 8.0.50727.4053 works, but 8.0.50727.42_x doesn't ;
this looks a lot to me exactly the same as winebug #16577;

http://bugs.winehq.org/show_bug.cgi?id=16577

Possibly the critical comment in that exposition is "[i]This would ideally work
but Wine's loader doesn't support the redirection of assembly bindings yet.[/i]"
--- I have no idea if that obstacle has been overcome -- I would say 'probably
not' as the bug itself is not marked resolved. There may be some contention here
as to how much of this is wine's fault, and how much of it actually relates back
to not yet having the .NET 2.0 SP1 & SP2 supports working...I'm not sure. I'm
reasonably sure however this is where your R6024 error is being spawn from....

The sound issue, going by your resolution description, is a case of the sound
capabilities not being advertised to the program in the way it wants to see
things, and it deduces we have no sound device and turns sound off. I've a
few apps like this on the Mac -- unfortunately the sound settings are tokenized
into binary files, so it's not as simple as opening and .ini file and editing ;-/

Any one (or more) of the following tea leaves could've caused the program to
erroneously configure itself for no sound output;

fixme:wave:wodDsCreate DirectSound not implemented
fixme:wave:wodDsCreate The (slower) DirectSound HEL mode will be used instead.
fixme:wave:AudioUnit_SetVolume independent left/right volume not implemented (1.000000, 1.000000)
warn:dsound:DirectSoundDevice_GetSpeakerConfig not fully functional

Possibly the first two lines explain it....ie; it goes looking for wodDsCreate DirectSound, gets
told that's not available, doesn't know what to do about DirectSound HEL (or doesn't bother having
another look), and so concludes to turn sound off in the config --- human being (you 8) comes along,
changes the ini file...surprise surprise, DirectSound HEL support does work (stoopid program ;)

Cheers and thanks for the legwork!

Great Don!

Hopefully someone will deal with the bug in wine. In the mean time it would be nice to find a work-a-round.

Creating work-a-rounds which perhaps can be added into a C4P file. Packing the file with the various components and fixes to get as close as possible to a good and easy working Dragon Age version 1.04.

Hi,

As said, I don't think there's a clean work-around for this one -
it's the makeup of the patch/installer itself making that call to
the the assembly bindings -- there is also a posting on wineHQ about
getting the 1.04 patch going....see;

http://appdb.winehq.org/objectManager.php?sClass=version&iId=18283

"Blog page with notes on getting 1.04 working"

That makes sense to me...ie; avoid the issue altogether by not having
any dependencies around during installation/patching, and -then- install
the required runtime dependencies for the game itself ; still may not work
because it looks like he was using wine-1.3.x but it'd be worth a shot...

C4P can't do that yet though (supposing it does work), but in the future
it should be able to handle it I think....let us know if that approach
works -- consider adding the 1.04 patch for DAO to that winebug too, might
add to it's momentum...

Cheers!

Artist Formally Known as Dot wrote:

...

http://appdb.winehq.org/objectManager.php?sClass=version&iId=18283

"Blog page with notes on getting 1.04 working"

That makes sense to me...ie; avoid the issue altogether by not
having
any dependencies around during installation/patching, and -then-
install
the required runtime dependencies for the game itself ; still may
not work
because it looks like he was using wine-1.3.x but it'd be worth a
shot...

...

Sounds interesting. I'll see if I can try that.