Dragon Age dlc issues

Open forum for end-user questions about Wine. Before asking questions, check out the Wiki as a first step.
Forum Rules
Locked
thorin
Level 3
Level 3
Posts: 50
Joined: Thu Feb 05, 2009 8:09 am

Dragon Age dlc issues

Post by thorin »

Hello. I've read through the dragon age wine appdb page, installed all the requisite stuff through winetricks, used a fresh prefix and all that, but my dlc in dragon age is always showing up as unauthorized. I'm pretty sure the dragon age updater service is running, it just can't seem to see my account as being authorized to use the dlc. I have in fact bought a couple of dlc's such as Warden's Keep and Return to Ostagar.

When I'm logged in, my bioware points total does show up, but no content in any of the three tabs as per the bug on the appdb page. When I install a dlc offer package, it shows up in the available downloads tab, but it shows up as only being available to buy. If anyone can help me sort this out, that would be fantastic. I've seen a few people writing that they can use their dlc without problems, despite the ongoing bug. I'm using the steam version, and I have the dapdatersvc service installed.

I'm running ubuntu maverick, with wine 1.3.3. I'm using the latest kernel from the mainline kernel site, latest nvidia drivers from the repos, etc. Any other details, just ask.
thorin
Level 3
Level 3
Posts: 50
Joined: Thu Feb 05, 2009 8:09 am

Post by thorin »

When I try to start the daupdatersvc service, I get the following in the terminal.

Code: Select all

 wine net start daupdatersvc
The Dragon Age: Origins Updater service is starting.
fixme:sync:CreateMemoryResourceNotification (0) stub
fixme:shell:URL_ParseUrl failed to parse L"System.ServiceProcess"
fixme:shell:URL_ParseUrl failed to parse L"System"
fixme:shell:URL_ParseUrl failed to parse L"DAUpdater.Engine"
fixme:shell:URL_ParseUrl failed to parse L"System.Configuration"
fixme:shell:URL_ParseUrl failed to parse L"System.Xml"
fixme:winsock:WSAIoctl SIO_GET_EXTENSION_FUNCTION_POINTER: unimplemented AcceptEx
fixme:winsock:WSAIoctl SIO_GET_EXTENSION_FUNCTION_POINTER: unimplemented GetAcceptExSockaddrs
fixme:winsock:WSAIoctl SIO_GET_EXTENSION_FUNCTION_POINTER: unimplemented TransmitFile
fixme:shell:URL_ParseUrl failed to parse L"mscorlib.resources"
fixme:shell:URL_ParseUrl failed to parse L"mscorlib.resources"
fixme:shell:URL_ParseUrl failed to parse L"System.resources"
fixme:shell:URL_ParseUrl failed to parse L"System.resources"
fixme:shell:URL_ParseUrl failed to parse L"System.ServiceProcess.resources"
fixme:shell:URL_ParseUrl failed to parse L"System.ServiceProcess.resources"
The Dragon Age: Origins Updater service was started successfully.
sirbubbles@sirbubbles-desktop:~$ 
I have dotnet30 installed.

When stopping the service, I get this.

Code: Select all

wine net stop daupdatersvc
The Dragon Age: Origins Updater service is stopping.
fixme:service:EnumDependentServicesW 0x124778 0x00000001 (nil) 0x00000000 0x32ed5c 0x32ed58 - stub
err:service:service_send_control service protocol error - failed to write pipe!
The Dragon Age: Origins Updater service was stopped successfully.
Anyone out there actually got this thing working?

I have installed the service by using dotnet's InstallUtil.exe to run daupdatersvc.service.exe in the game's bin_ship folder. Did this because I don't think the Steam version of Dragon Age installs the service properly straight off. When I start the game I do see daupdater.service.exe in the wine task manager briefly, so I believe the service is actually starting.
wulfen
Newbie
Newbie
Posts: 3
Joined: Fri Dec 31, 2010 9:39 pm

Post by wulfen »

Going through exactly the same stuff.
Currently researching down this path:
fixme:winsock:WSAIoctl SIO_GET_EXTENSION_FUNCTION_POINTER: unimplemented TransmitFile

correlated with the DragonAge_1.log entries that look like this:

DA Download Manager (DADM) Attempting to connect to DADM Control Server!
DA Download Manager (DADM) Connected to DADM Control Server!
DA Download Manager (DADM) Failed to configure DADM!
DA Download Manager (DADM) Disconnected from DADM Control Server!


Here's a reference to which dll this might sit in:
http://www.gamedev.net/community/forums ... _id=323809

Will post more if I find a resolution.
User avatar
DanKegel
Moderator
Moderator
Posts: 1164
Joined: Wed May 14, 2008 11:44 am

Post by DanKegel »

Good point... I suggested in
http://bugs.winehq.org/show_bug.cgi?id=20716
just now that maybe it would help to fix
SIO_GET_EXTENSION_FUNCTION_POINTER to handle TransmitFile
(which has been implemented for a while now).
wulfen
Newbie
Newbie
Posts: 3
Joined: Fri Dec 31, 2010 9:39 pm

Post by wulfen »

I'll write a wrap-up blog, but at the moment, I've made incremental progress. Current failure (using winehacks repo as a starting point, and adding a small bit of code from there) is:

fixme:winsock:AcceptEx Failed to query async: c0000008

Not sure if this is
a) firewall (Seeing strange martions from .254)
b) the AcceptEx implementation, which promises (and looks like) it properly supports async
c) most likely, the TransmitPackets/TransmitFile implementation I'm starting with (details below), which admittedly "fakes" the async. However from that perspective it simply means your supposedly "async kickoff call" followed by "calls to callback" just needs to call the callback before returning(?) since the call blocked... anyway

The sad thing about the fix to bug 5048 (CLICK), which is the one asking for a TransmitFile implementation, is that it relies on a call to this same (SIO_GET_EXTENSION_FUNCTION_POINTER) : the implementation boils down to:
/* Use the implementation provided by ws2_32 */
if (WSAIoctl(s, SIO_GET_EXTENSION_FUNCTION_POINTER,
(void*)&guid, sizeof(guid), &fn, sizeof(fn), &len, NULL, NULL))
return fn(...);
return FALSE;

- the commiter did end with "now on to implementation side", but that was about 2 years 3 months ago


Two people out there have tried implementing TransmitFile/TransmitPackets. This guy http://wine.1045685.n5.nabble.com/templ ... user=54669 put his implementation in dlls/mswsock/mswsock.c. Latest I could find from him was in 2006, and there were several reasons his patch was rejected, mostly poor timing (busy week??) ...
The better place is where the other guy (http://wine.1045685.n5.nabble.com/templ ... user=34498, specifically (CLICK) ) tried, at dlls/socket/socket.c (sitting next to the SIO_EXTENSION call, since wine .dll relocation is reputedly (?) tricky to deal with). In any case, both have failed to get in for various reasons.
However, latest attempt was 17/7/2008, and the only trace I can find is this feedback from Alexandre:

http://www.winehq.org/pipermail/wine-de ... 67452.html


In any case, this looked like an interesting starting point. winehacks gave me a basis where SIO_EXTENSION... has a (working or non, debatable, see below) AcceptEx, enough that this has helped folks play Warcraft 3 and similar (e.g. bug ), and here was a (apparently incorrect) attempt at an implementation of TransmitFile/TransmitPackets.

So, I've:

1. Fetched the repo at http://repo.or.cz/w/wine/hacks.git

2. Applied the changes from the patch manually to:
(wine-src)/include/mswsock.h,
(wine-src)/dlls/ws2_32/socket.c

3. Got a good make out of dlls/ws2_32.

4. Moved my ws2_32.dll.so out of the way, and dropped this one in place, in /usr/lib32/wine (it is about twice the size 499k vs 199k). I didn't do anything special on .configure or make depends, so I'm not sure if debug switches are on by default, but that seemed relatively large.


In any case, I can now do the following:

1. Launch steam. This gets me an active process in the wine prefix. I'm assuming wineserver has something to do with this, because, I can then:
2. BEFORE Starting DA:O Ultimate Nightmare for Wine, find shell, launch:
WINEPREFIX=~/.PlayOnLinux/wineprefix/Steam wine net start daoupdatersvc

2.a Side note, I noticed at this point, that in addition to the ports mentioned here:(http://social.bioware.com/forum/1/topic/58/index/359507), my firewall starts rejecting TCP traffic on 9946 from my machine; the target IP is not nslookup-able, but tracert goes right to EA. So, I opened that up.

3. Verify it started by running the above again. You'll get a message saying service started. (Try this prior to starting steam, and you will see your virtual desktop (if you run that way) start and stop, and each time it will state "successfully started service")


5. If you've launched steam from command (e.g. WINEPREFIX=~/.PlayOnLinux/wineprefix/Steam wine "c:\\Program Files\\Steam\\steam.exe"), I see that the fixme::TransmitFile warnings have gone away, and now I see AcceptEx warnings.



More info:

Here's console output from running the daupdatersvc:
Before this /usr/lib32/wine/ws2_32.dll.so replacement:
me@minotaur:~/.PlayOnLinux/wineprefix/Steam/drive_c/Program Files$ WINEPREFIX=/home/me/.PlayOnLinux/wineprefix/Steam/ wine net start daupdatersvc
The Dragon Age: Origins - Content Updater service is starting.
fixme:sync:CreateMemoryResourceNotification (0) stub
fixme:shell:URL_ParseUrl failed to parse L"System.ServiceProcess"
fixme:shell:URL_ParseUrl failed to parse L"System"
fixme:shell:URL_ParseUrl failed to parse L"DAUpdater.Engine"
fixme:shell:URL_ParseUrl failed to parse L"System.Configuration"
fixme:shell:URL_ParseUrl failed to parse L"System.Xml"
fixme:winsock:WSAIoctl SIO_GET_EXTENSION_FUNCTION_POINTER: unimplemented TransmitFile
The Dragon Age: Origins - Content Updater service was started successfully.

After this /usr/lib32/wine/ws2_32.dll.so replacement:
me@minotaur:~/.PlayOnLinux/wineprefix/Steam/drive_c/Program Files$ WINEPREFIX=/home/me/.PlayOnLinux/wineprefix/Steam/ wine net start daupdatersvc
The Dragon Age: Origins - Content Updater service is starting.
fixme:sync:CreateMemoryResourceNotification (0) stub
fixme:shell:URL_ParseUrl failed to parse L"System.ServiceProcess"
fixme:shell:URL_ParseUrl failed to parse L"System"
fixme:shell:URL_ParseUrl failed to parse L"DAUpdater.Engine"
fixme:shell:URL_ParseUrl failed to parse L"System.Configuration"
fixme:shell:URL_ParseUrl failed to parse L"System.Xml"
fixme:winsock:AcceptEx Failed to query async: c0000008
The Dragon Age: Origins - Content Updater service was started successfully.
rloh@minotaur:~/.PlayOnLinux/wineprefix/Steam/drive_c/Program Files$


NOTE!! DESPITE .PlayOnLinux in the path, note I am NOT using it to launch. I typically use POL for things like easy setup & install, Point & Click winecfg when I'm feeling lazy, and closing all processes in a wineprefix (can someone give me a reliable ps filter? open file handles or ..? maybe specify cwd of each process.. and filter based on what each prefix is..?)


Doing a tail -f or refreshing the file in gedit/gvim/etc ~/BioWare/Dragon Age/Logs/DragonAge_1.log spins the following in a series (once for each addon)

DA Download Manager (DADM) Attempting to connect to DADM Control Server!
DA Download Manager (DADM) Connected to DADM Control Server!
DA Download Manager (DADM) Failed to configure DADM!
DA Download Manager (DADM) Disconnected from DADM Control Server!

followed by the wallet balance check. I did notice the wallet balance checks happening (without future dadm messages) while hitting refresh on available content page (which shows everything with a points value), thought I can't be positive now with all the iterations I've tried, whether that's because I didn't do something like logout/login in between.

Which I've tried btw, (logout, login), it just yeilds more of those blocks of DADM messages/wallet balance checks.

The heart of this problem looks like some very simple service code that just wants to pick up what's likely an authentication file....

Going to look at the implementation of TransmitPackets a bit closer, see if I can make it async... Anyone who has thoughts/more info, please provide =)
wulfen
Newbie
Newbie
Posts: 3
Joined: Fri Dec 31, 2010 9:39 pm

Post by wulfen »

Hey Folks, there is an easy answer here:

http://social.bioware.com/forum/1/topic ... /8#5246044

This works for me because I'm in an state where I've installed the DA:O Ultimate edition from Steam, which comes with all the expansion packs.

So, nothing additional needs to be downloaded, and everything "gels" because the add in packs now don't check for authorization.

Ugh, way too much in the guts of WINE for me to be happy with this solution but once I discovered what I did (below), I became convinced that I was on a red herring.

In any case, hope this helps some folks.

----

Notes:

So, I realized that AcceptEx and GetAcceptExSockaddr had been implemented in the trunk of wine (1.3.10), so I moved the TransmitFile code over there, and after a bit of poking figured out that TransmitFile is not even being called... Possibly by the service, but I wasn't able to see any output after doing the net start...
Locked