http://bugs.winehq.org/show_bug.cgi?id=7705
andrey.turkin(a)gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |andrey.turkin(a)gmail.com
------- Additional Comments From wine(a)kapila.force9.co.uk 2007-15-03 05:55 -------
Additional Information:
Crash is occurring in the Everquest2.exe process.
Before the crash, SymInitializeW is called with a process handle 0xffffffff.
process_find_by_handle finds an existing process with this handle.
For some reason, another process structure is allocated after this, so the next
call to process_find_by_handle finds TWO processes with the handle 0xffffffff
and returns the second one (Though changing the code to return the first one
makes no difference).
SymInitializeW returns successfully.
Then SymFromAddr is called a few times, and each time symt_find_nearest returns
FALSE, because the following lines
symt_get_info(&module->addr_sorttab[0]->symt, TI_GET_ADDRESS, &ref_addr);
if (addr < ref_addr) return NULL;
This is as far as I have been able to trace it. I cannot run with +relay enabled
as this causes things to slow down so much that the game times out before the
crash. Is there anyway I can enable the + relay from the code? (eg when the
above lines of code are called?
------- Additional Comments From andrey.turkin(a)gmail.com 2007-18-04 17:19 -------
Native dbghelp.dll use some sort of reference counting for process structure, so
it can recover from multiply SymInitialize/SymCleanup calls with identical
hProcess (native increments refcount, returns TRUE and, strangely enough, sets
last error to ERROR_INVALID_HANDLE).
You can try hacky approach - to return from SymInitialize immediately when
process_find_by_handle finds record (just put return TRUE; instead of
FIXME("What to do?"). Proper way is probably to implement refcounter.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=8101
madewokherd(a)gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |download
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=8101
Summary: Worms Armageddon and Worms World Party stop responding
to input after closing dialogs
Product: Wine
Version: 0.9.35.
Platform: PC
URL: http://wwp.team17.com/main.html?page=comm&area=_down_dem
o
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-user
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: madewokherd(a)gmail.com
After closing a dialog in the WA or WWP frontend when in virtual desktop mode,
the frontend no longer responds to input.
I know the WA frontend uses user.dll for its controls (i.e. they are real
windows controls with real windows) and ddraw to draw them, so I'm filing this
under user.
I remember discovering when poking at this earlier that after the dialogs are
closed, another window (whose purpose is unknown to me) actually obscures WA's
main window that has the controls. The controls are still visible because ddraw
draws over everything (this is not wine's normal behavior but it is the correct
behavior and it's how the patches for bug 2082 work) but according to the
windowing system they are obscured. I assume that means they get no input events.
I do not know why that happens or why this works in windows.
This can be reproduced by running the WWP demo (see the howto at
http://appdb.winehq.org/appview.php?iVersionId=3905) and attempting to start a
network game (the demo doesn't allow this and creates a dialog to let you know).
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=8100
madewokherd(a)gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |download
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=8100
Summary: Worms Armageddon and Worms World Party sound glitches
Product: Wine
Version: 0.9.35.
Platform: PC
URL: http://wwp.team17.com/main.html?page=comm&area=_down_dem
o
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-directx-dsound
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: madewokherd(a)gmail.com
Worms Armageddon and World World Party require native quartz and devenum dlls
for the sound to work properly.
They used to crash with builtin quartz (which was actually a regression so now
we're back to the original problem which I'm about to describe), but now the
sound glitches in different ways depending on the sound driver. With OSS, the
sound works fine for a while and then turns to static at random times. With
ALSA, there's a sort of "echo" effect that's difficult to describe.
This problem can be reproduced with the WWP demo, when can be installed/run as
described in the howto at http://appdb.winehq.org/appview.php?iVersionId=3905
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=8099
Summary: Silverlight aka WPF/e plugin can't display silverlight
test page
Product: Wine
Version: CVS
Platform: Other
URL: http://www.microsoft.com/silverlight/downloads.aspx
OS/Version: other
Status: NEW
Keywords: download
Severity: normal
Priority: P2
Component: wine-shdocvw
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: dank(a)kegel.com
Set WinXP mode in winecfg.
Download and install Firefox 1.5.x.
Download and install Silverlight msi package.
Restart Firefox. about:plugins should show silverlight plugin loaded.
In firefox, go to silverlight test page,
http://www.microsoft.com/silverlight/
Plugin aborts and puts up a dialog that says something like
"this plugin has failed, please restart browser"
The console shows
wine: Call from 0x137b4ae to unimplemented function
urlmon.dll.CreateURLMonikerEx, aborting
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=8097
dank(a)kegel.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |download
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=8098
dank(a)kegel.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID
------- Additional Comments From dank(a)kegel.com 2007-18-04 16:28 -------
Unless this is causing the program to misbehave, this is not a bug.
(Maybe after we get all the apps working, we can worry
about cosmetic details like too many warnings...)
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=6764
------- Additional Comments From dank(a)kegel.com 2007-18-04 16:07 -------
Full +msi,+relay log is 1.0GB long, and compressed down to
ten megabytes with rzip (quickly, too). Full file at
http://kegel.com/wine/dns9-log.rz
Looks like it's barfing installing an msxml3 merge module
because a file is missing:
trace:msi:HANDLE_CustomType1 Calling function L"Wdsfpca_DoInstallWFPFile" from
L"C:\\windows\\temp\\msi1fa4.tmp"
...
0083:Call msi.MsiRecordSetStringW(0000003a,00000000,00763a68 L"Success:
msoobci.dll is loaded successfuly from 'C:\\windows\\temp\\mso4e76.tmp'")
ret=00507eae
...
0083:Call msi.MsiRecordSetStringW(0000003a,00000000,00763a68 L"Source path of
exception pack: 'c:\\Program Files\\Common Files\\Microsoft Shared\\SFPCA
Cache\\'") ret=00507eae
...
0083:Call setupapi.SetupOpenInfFileW(7c446ca0 L"c:\\Program Files\\Common
Files\\Microsoft Shared\\SFPCA Cache\\msxmlx.inf",00000000,00000002,00000000)
ret=00505444
0083:Call kernel32.CreateFileW(00759880 L"C:\\Program Files\\Common
Files\\Microsoft Shared\\SFPCA
Cache\\msxmlx.inf",80000000,00000001,00000000,00000003,00000000,00000000)
ret=7c2a5654
0083:Ret kernel32.CreateFileW() retval=ffffffff ret=7c2a5654
0083:Ret setupapi.SetupOpenInfFileW() retval=ffffffff ret=00505444
...
0083:Call msi.MsiRecordSetStringW(0000003a,00000000,00763a68 L"Error:
'msxmlx.inf' with error code 1 (0x1)") ret=00507eae
...
err:msi:ITERATE_Actions Execution halted, action L"InstallFinalize" returned 1603
That file, msxmlx.inf, was installed to c:\windows\system32. So
perhaps our msi is putting it in the wrong place...
There's also a dgnsetup.log left in c:\windows\temp which is
somewhat interesting if you want it.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=3615
------- Additional Comments From l_bratch(a)yahoo.co.uk 2007-18-04 15:31 -------
I think it's multithreaded D3D that's stopping the game Rainbow Six Vegas
running too. Does anyone know this for sure, or is there some debug channel I
can post to confirm it? I know applying one of Stefan's opengl thread context
patchsets allowed it to get into the menu a few weeks ago, but that doesn't seem
to work any more...
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.