WineHQ Bugzilla – Bug 32762 – Worms Forts Under Siege crashes on startup (Safedisc v4.00.000)

Bugzilla

Last modified: 2013-12-20 12:43:23 UTC

Worms Forts Under Siege crashes on startup (Safedisc v4.00.000)

Bug 32762 - Worms Forts Under Siege crashes on startup (Safedisc v4.00.000)


Summary:	Worms Forts Under Siege crashes on startup (Safedisc v4.00.000)

Status:	CLOSED FIXED

AppDB:	Show Apps affected by this bug
Product:	Wine
Classification:	Unclassified
Component:	-unknown
Version:	1.5.22
Hardware:	x86-64 Linux

Importance:	P2 normal
Target Milestone:	---
Assigned To:	Mr. Bugs

URL:
Keywords:	obfuscation

Depends on:
Blocks:
	Show dependency tree

Reported:	2013-01-19 22:35 UTC by Murray Colpman
Modified:	2013-12-20 12:43 UTC (History)
CC List:	1 user (show)

See Also:
Regression SHA1:
Fixed by SHA1:
Distribution:	---
Staged patchset:

Attachments
backtrace of crash (6.02 KB, text/plain) 2013-01-19 22:35 UTC, Murray Colpman	Details
View All Add an attachment (back traces, logs, proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Murray Colpman 2013-01-19 22:35:19 UTC

Created attachment 43242 [details]
backtrace of crash

This is a really weird issue, which I'm going to try to investigate further because it's so odd. I've installed Worms Forts Under Siege on my laptop, a Thinkpad T410 with a Panasonic UJ892 DVD drive. After manually fixing the already-reported issue with the 64-bit system and the copy protection driver (SafeDisc v4.00.000 according to ProtectionID), when I attempt to run it now, it displays a small white square in the middle of the screen for a good few minutes, then crashes with a page fault on write with a standard backtrace, attached. What's weird is what happens next - despite the program cleanly exiting and nothing (according to lsof) using the filesystem or hardware device, the disc drive then completely freezes. You can unmount it, but after that, you can't remount it, you can't eject it (with eject or with the button), it stays spun-up forever, and if you manually eject it it doesn't detect that the disc has been removed/replaced and doesn't spin up when you reinsert the disc. The only way to get it back AFAICT is to eject the whole drive from the bay and reinsert, or presumably to reboot.

I don't know which part of this, if any, is a wine bug, and which (surely partially) is a driver/hardware/possibly BIOS bug (does the BIOS have any hand in things?), but I thought it'd be best to report it just in case. I'm going to try using someone else's drive (I have many friends with different models of ThinkPad, the bays all hopefully being compatible) to see if it exists there. On my 32-bit desktop, the game runs fine on all three drives past the point where it would have crashed here (but crashes shortly afterwards anyway with presumably a different bug).


Incidentally, running wine in Win9x mode causes the copy protection system to detect a debugger; running it in Win2k mode causes the program to silently exit; XP and above cause as described.

Comment 1 Austin English 2013-01-20 14:34:27 UTC

Likely a kernel bug.

Comment 2 Murray Colpman 2013-01-20 16:01:00 UTC

Mmm. I don't know whether the drive stopping responding causes the program to crash in wine, or vice versa, though, so I thought I'd report it here just in case the program crashing in wine part of this is, in fact, a wine bug.

Comment 3 Anastasius Focht 2013-12-17 08:45:36 UTC

Hello folks,

I can't reproduce the problem, the game installs and runs fine here.

The drive kept spinning because of the crash in media validation phase.

--- snip ---
Module  Address                 Debug info      Name (75 modules)
PE        330000-  3ab000       Deferred        msvcp71
PE        400000-  762000       Deferred        wf
PE      10000000-10050000       Export          ~dead78.tmp
PE      66700000-668e7000       Deferred        ~df394b.tmp
...
0000002a (D) C:\Program Files (x86)\Team17 Software Ltd\Worms Forts Under Siege\WF.exe
        00000033    0
        0000002b    0 <==
--- snip ---

In general a 32-bit WINEPREFIX (WINEARCH=win32) should be preferred for copy-protected games (see bug 30901).
If you manually 'fix' issues with drivers/services in 64-bit environment do it at your own risk.

Protection scan:

--- snip ---
-=[ ProtectionID v0.6.5.5 OCTOBER]=-
(c) 2003-2013 CDKiLLER & TippeX
Build 31/10/13-21:09:09
Ready...
Scanning -> Z:\home\focht\.wine\drive_c\Program Files (x86)\Team17 Software Ltd\Worms Forts Under Siege\WF.exe
File Type : 32-Bit Exe (Subsystem : Win GUI / 2), Size : 5029372 (04CBDFCh) Byte(s)
-> File has 1629692 (018DDFCh) bytes of appended data starting at offset 033E000h
[File Heuristics] -> Flag : 00000000000000000100000000000111 (0x00004007)
[Entrypoint Section Entropy] : 6.47
[!] Safedisc v4.00.000 detected !
[i] Appended data contents....
   [.] o: 0x0033E028  / t: <0xA8726B03> <0xEF01996C> <0x00000001> / s: 00212159 byte(s) -> ~dead78.tmp
   [.] o: 0x00371D0E  / t: <0xA8726B03> <0xEF01996C> <0x0000044C> / s: 00011922 byte(s) -> clcd32.dll
   [.] o: 0x00374BC7  / t: <0xA8726B03> <0xEF01996C> <0x0000044C> / s: 00004122 byte(s) -> clcd16.dll
   [.] o: 0x00375C05  / t: <0xA8726B03> <0xEF01996C> <0x0000044D> / s: 00037971 byte(s) -> mcp.dll
   [.] o: 0x0037F07F  / t: <0xA8726B03> <0xEF01996C> <0x00000002> / s: 00137721 byte(s) -> SECDRV.SYS
   [.] o: 0x003A0A9F  / t: <0xA8726B03> <0xEF01996C> <0x00000002> / s: 00019150 byte(s) -> DrvMgt.dll
   [.] o: 0x003A5596  / t: <0xA8726B03> <0xEF01996C> <0x0000000B> / s: 00005446 byte(s) -> SecDrv04.VxD
   [.] o: 0x003A6B01  / t: <0xA8726B03> <0xEF01996C> <0x00000000> / s: 00073276 byte(s) -> ~e5.0001
   [.] o: 0x003B8964  / t: <0xA8726B03> <0xEF01996C> <0x00000000> / s: 00040960 byte(s) -> PfdRun.pfd
   [.] o: 0x003C298C  / t: <0xA8726B03> <0xEF01996C> <0x00000000> / s: 01086492 byte(s) -> ~df394b.tmp
[CompilerDetect] -> Visual C++ 7.1 (Visual Studio 2003)
- Scan Took : 0.481 Second(s) [0000001E1h tick(s)] [533 scan(s) done]
--- snip ---

Regards

Comment 4 Alexandre Julliard 2013-12-20 12:43:23 UTC

Closing bugs fixed in 1.7.9.