http://bugs.winehq.org/show_bug.cgi?id=16893
Summary: .NET 3.0: Windows Workflow Foundation post-install:
loadperf needs LoadPerfCounterTextStringsA/W stubs
Product: Wine
Version: 1.1.12
Platform: Other
URL: http://www.microsoft.com/downloads/details.aspx?FamilyID
=10cc340b-f857-4a14-83f5-25634c3bf043
OS/Version: other
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Hello,
after getting past bug 16891 the WF post install fails while running
performance counter registration.
Thanks to recent fixture of bug 12099 we have loadperf dll already in place...
--- snip ---
...
wine: Call from 0x7b844f54 to unimplemented function
loadperf.dll.LoadPerfCounterTextStringsW, aborting
fixme:advapi:CheckTokenMembership (0x188 0x1baf48 0x33e2c8) stub!
fixme:imm:ImmDisableIME (-1): stub
fixme:thread:NtQueryInformationThread Cannot get kerneltime or usertime of
other threads
fixme:thread:NtQueryInformationThread info class 9 not supported yet
fixme:thread:NtQueryInformationThread info class 9 not supported yet
fixme:thread:NtQueryInformationThread info class 9 not supported yet
fixme:advapi:RegisterEventSourceW ((null),L".NET Runtime 2.0 Error Reporting"):
stub
fixme:advapi:ReportEventW
(0xcafe4242,0x0001,0x0000,0x000003e8,(nil),0x0008,0x0000011a,0x3009a1b4,0x7ed505c0):
stub
err:eventlog:ReportEventW L"performancecounterinstaller.exe"
err:eventlog:ReportEventW L"3.0.4203.2"
err:eventlog:ReportEventW L"44c6ca00"
err:eventlog:ReportEventW L"kernel32.dll"
err:eventlog:ReportEventW L"5.1.2600.2180"
err:eventlog:ReportEventW L"00000000"
err:eventlog:ReportEventW L"0"
err:eventlog:ReportEventW L"00024f54"
fixme:advapi:DeregisterEventSource (0xcafe4242) stub
fixme:thread:NtQueryInformationThread info class 9 not supported yet
fixme:thread:NtQueryInformationThread info class 9 not supported yet
fixme:thread:NtQueryInformationThread info class 9 not supported yet
Unhandled Exception: System.Runtime.InteropServices.SEHException: External
component has thrown an exception.
at System.Workflow.NativeMethods.LoadPerfCounterTextStrings(String
commandLine, Boolean quietMode)
at System.Workflow.PerformanceCounterInstaller.Install()
at System.Workflow.PerformanceCounterInstaller.Main(String[] args)
wine: Unimplemented function loadperf.dll.LoadPerfCounterTextStringsW called at
address 0x7b844f54 (thread 000c), starting debugger...
Unhandled exception: unimplemented function
loadperf.dll.LoadPerfCounterTextStringsW called in 32-bit code (0x7b844fd7).
--- snip ---
To reproduce this problem manually, execute the following:
--- snip ---
$ pwd
/home/focht/.wine/drive_c/windows/Microsoft.NET/Framework/v3.0/Windows Workflow
Foundation
$ wine ./PerformanceCounterInstaller.exe uninstall
...
$ wine ./PerformanceCounterInstaller.exe install
--- snip ---
The uninstall step is needed otherwise the registry keys are not explicitly
removed and "install" will short-circuit, not doing anything useful.
With stubs to loadperf added in similar manner like
UnloadPerfCounterTextStringsA/W, we can get past this:
--- snip ---
$ WINEDEBUG=+tid,+seh,+loadperf wine ./PerformanceCounterInstaller.exe install
...
0009:trace:loadperf:DllMain (0x0x60cb0000, 1, (nil))
0009:fixme:loadperf:LoadPerfCounterTextStringsW (L"
\"C:\\windows\\Microsoft.NET\\Framework\\v3.0\\Windows Workflow
Foundation\\PerfCounters.ini\"", 1): stub
...
--- snip ---
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=17902
Summary: ole32.CoGetClassObject: threads without apartment should
use existing MTA
Product: Wine
Version: 1.1.18
Platform: Other
URL: http://www.microsoft.com/downloads/details.aspx?FamilyID
=fe6f2099-b7b4-4f47-a244-c96d69c35dec
OS/Version: other
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ole32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Hello,
there are apps which use free threaded COM (inproc) servers and call
CoGetClassObject() from (new) threads that do not explicitly initialize COM.
This is valid behaviour when one of the existing threads already created the
MTA by calling CoInitializeEx(NULL, COINIT_MULTITHREADED).
See: http://support.microsoft.com/kb/150777
--- quote ---
Current implementations of COM allow a thread that does not explicitly
initialize COM to be a part of the MTA. A thread that does not initialize COM
is part of the MTA only if it starts using COM after at least one other thread
in the process has previously called CoInitializeEx(NULL,
COINIT_MULTITHREADED). (It is even possible that COM itself may have
initialized the MTA when no client thread has explicitly done so; for example,
a thread associated with an STA calls CoGetClassObject/CoCreateInstance[Ex] on
a CLSID that is marked "ThreadingModel=Free" and COM implicitly creates an MTA
into which the class object is loaded.) See the information on threading model
interoperability below.
However, this is a configuration that might cause problems, such as access
violations, under certain circumstances. Therefore, it is strongly recommended
that each thread that needs to do COM work initialize COM by calling
CoInitializeEx and then, on completion of COM work, call CoUninitialize. The
cost of "unnecessarily" initializing an MTA is minimal.
--- quote ---
An example app suffering from this is the managed console debugger from .NET
2.0 SDK "cordbg.exe":
When trying to debug a simple console C# app created with symbols (.pdb
format):
--- snip ---
wine "C:\\windows\\Microsoft.NET\\Framework\\v2.0.50727\\csc.exe" /debug+
foo.cs
--- snip ---
Start debugger:
--- snip ---
wine "C:\\Program Files\\Microsoft.NET\\SDK\\v2.0\\Bin\\cordbg.exe foo.exe"
--- snip ---
The debugger will immediately begin to execute the app - not halting in Main()
method (source).
This is because symbol information can't be loaded using COR symbol binder
which lives in a free threaded COM inproc server.
0A29FF9E-7F9C-4437-8B11-F424491E3931 -> CLSID_CorSymBinder
Threads 0x38 (main) and 0x36 call "CoInitializeEx" with COINIT_MULTITHREADED,
creating the MTA.
Thread 0x3b is created later as pooled thread - part of MTA - to serve CLR
debugger requests (work items).
That thread never makes any init calls to COM (verified).
--- snip ---
...
0038:Call KERNEL32.GetProcAddress(60970000,7a37e2ae "CoInitializeEx")
ret=79e9d311
0038:Ret KERNEL32.GetProcAddress() retval=609750c8 ret=79e9d311
0038:Call ole32.CoInitializeEx(00000000,00000000) ret=79ebfba8
0038:Call ntdll.RtlAllocateHeap(00110000,00000008,000000fc) ret=60986499
0038:Ret ntdll.RtlAllocateHeap() retval=0014f9c0 ret=60986499
0038:Call ntdll.RtlAllocateHeap(00110000,00000000,00000028) ret=609a750c
0038:Ret ntdll.RtlAllocateHeap() retval=001500e8 ret=609a750c
0038:Call KERNEL32.InitializeCriticalSection(001500f8) ret=609a7543
0038:Ret KERNEL32.InitializeCriticalSection() retval=00000001 ret=609a7543
0038:Call ntdll.RtlAllocateHeap(00110000,00000008,0000007c) ret=60983f54
0038:Ret ntdll.RtlAllocateHeap() retval=00151df0 ret=60983f54
0038:Call KERNEL32.InitializeCriticalSection(00151e10) ret=60983fb4
0038:Ret KERNEL32.InitializeCriticalSection() retval=00000001 ret=60983fb4
0038:Ret ole32.CoInitializeEx() retval=00000000 ret=79ebfba8
...
0036:Call ole32.CoInitializeEx(00000000,00000000) ret=79ebfba8
0036:Call ntdll.RtlAllocateHeap(00110000,00000008,000000fc) ret=60986499
0036:Ret ntdll.RtlAllocateHeap() retval=00151e78 ret=60986499
0036:Ret ole32.CoInitializeEx() retval=00000000 ret=79ebfba8
...
003b:Call advapi32.RegOpenKeyExW(80000000,0310d170
L"CLSID\\{0A29FF9E-7F9C-4437-8B11-F424491E3931}\\InprocServer32",00000000,00020019,0310d0dc)
ret=79ea5b8a
003b:Ret advapi32.RegOpenKeyExW() retval=00000000 ret=79ea5b8a
003b:Call
...
003b:Call advapi32.RegOpenKeyExW(00000238,0310d270
L"2.0.50727",00000000,00020019,0310d0ec) ret=79ea5b8a
003b:Ret advapi32.RegOpenKeyExW() retval=00000000 ret=79ea5b8a
003b:Call advapi32.RegQueryValueExW(0000023c,7a136a40
L"ImplementedInThisVersion",00000000,0310d0e4,00000000,0310d0e8) ret=79ea5bd0
003b:Ret advapi32.RegQueryValueExW() retval=00000000 ret=79ea5bd0
003b:Call advapi32.RegCloseKey(0000023c) ret=7a1369f2
003b:Ret advapi32.RegCloseKey() retval=00000000 ret=7a1369f2
...
003b:Call advapi32.RegOpenKeyExW(80000000,0310d318
L"CLSID\\{0A29FF9E-7F9C-4437-8B11-F424491E3931}\\InprocServer32\\2.0.50727",00000000,00020019,0310d314)
ret=79ea5b8a
003b:Ret advapi32.RegOpenKeyExW() retval=00000000 ret=79ea5b8a
003b:Call advapi32.RegQueryValueExW(00000238,79f873d0
L"Class",00000000,0310d2f8,00000000,0310d310) ret=79ea5bd0
003b:Ret advapi32.RegQueryValueExW() retval=00000002 ret=79ea5bd0
003b:Call advapi32.RegCloseKey(00000238) ret=79f88946
003b:Ret advapi32.RegCloseKey() retval=00000000 ret=79f88946
...
003b:Call KERNEL32.GetProcAddress(60970000,7a37e222 "CoGetClassObject")
ret=79e9d311
003b:Ret KERNEL32.GetProcAddress() retval=60974f78 ret=79e9d311
003b:Call ole32.CoGetClassObject(00175d3c,00000015,00000000,79f83a7c,0310d5e8)
ret=7a041335
003b:err:ole:CoGetClassObject apartment not initialised
003b:Ret ole32.CoGetClassObject() retval=800401f0 ret=7a041335
003b:Call KERNEL32.GetLastError() ret=79e74ab4
003b:Ret KERNEL32.GetLastError() retval=0000007f ret=79e74ab4
000007f ret=78132d14
...
003b:Call
KERNEL32.FormatMessageW(000031ff,00000000,800401f0,00000400,0310d4f4,00000000,0310d4a0)
ret=7a127c38
003b:Ret KERNEL32.FormatMessageW() retval=00000000 ret=7a127c38
--- quote ---
The failure is due to Wine's CoGetClassObject() rejecting requests when no
apartment in current thread (oletls) exists.
--- snip dlls/ole32/compobj.c ---
HRESULT WINAPI CoGetClassObject(
REFCLSID rclsid, DWORD dwClsContext, COSERVERINFO *pServerInfo,
REFIID iid, LPVOID *ppv)
{
LPUNKNOWN regClassObject;
HRESULT hres = E_UNEXPECTED;
APARTMENT *apt;
TRACE("\n\tCLSID:\t%s,\n\tIID:\t%s\n", debugstr_guid(rclsid),
debugstr_guid(iid));
if (!ppv)
return E_INVALIDARG;
*ppv = NULL;
apt = COM_CurrentApt();
if (!apt)
{
ERR("apartment not initialised\n");
return CO_E_NOTINITIALIZED;
}
...
--- snip dlls/ole32/compobj.c ---
Rather than failing CoGetClassObject() without apartment, it should look for an
existing MTA and let the current thread use it.
With the MTA being used, the inproc server is created and the app works as
intended, e.g. symbols get loaded, source can be stepped ...
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=17212
Summary: Unimplemented function ntoskrnl.exe.KeInitializeMutex
Product: Wine
Version: 1.1.13
Platform: PC-x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ntoskrnl
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: mc2374(a)mclink.it
Created an attachment (id=19133)
--> (http://bugs.winehq.org/attachment.cgi?id=19133)
Console output from the aborted installation
Trying to install Acronis True Image Home 11.
After some 'err' and 'fixme' (mostly in the msi component), the installation
process halts with the above console message and throws an unhandled exception.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16041
Summary: Acronis Crash while install
Product: Wine
Version: 1.1.8
Platform: Other
OS/Version: other
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: james2432(a)gmail.com
Created an attachment (id=17266)
--> (http://bugs.winehq.org/attachment.cgi?id=17266)
Backtrace of acronis 12 crashing
While running the acronis home 12 the installer crashes
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16626
Summary: NBC Direct installer requires installation of Windows
Installer 3.1 redist
Product: Wine
Version: 1.1.11
Platform: PC
URL: http://www.nbc.com/Video/NBCDirectInstaller.exe
OS/Version: Linux
Status: NEW
Keywords: dotnet, download, Installer
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: austinenglish(a)gmail.com
CC: focht(a)gmx.net, yolande(a)haneder.biz
Created an attachment (id=18188)
--> (http://bugs.winehq.org/attachment.cgi?id=18188)
terminal output in git
Continuing from bug 12477, NBC installer doesn't yet work. Prereq's:
$ rm -rf ~/.wine
$ winetricks -q wmp10 dotnet20 mdac28
$ wine NBCDirectInstaller.exe
Fails with an error box:
SetupManager Error
'Failed to update Select Dialog resources from an external resource file.
Please verify that the SetupManagerResource.resx files resides beside
executable and is valid. Error details: No access to memory location
OK
Anastasius suggested to file the bug, saying it probably affects more dotnet
apps.
Terminal output attached.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=17991
Summary: QueryPathOfRegTypeLib fails to locate typelib when
(major.minor) = (0xffff.0xffff)
Product: Wine
Version: 1.1.18
Platform: Other
OS/Version: other
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: oleaut32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Hello,
oleauto32.QueryPathOfRegTypeLib() doesn't work correctly when (major.minor) =
(0xffff.0xffff).
These parameters are passed by .NET Framework/CLR when regasm.exe utility is
used to export and register typelibs from .NET assemblies.
E.g. something like this:
--- snip ---
$ wine regasm.exe foo.dll /codebase /tlb
--- snip ---
WINEDEBUG=+tid,+seh,+ole,+reg
--- snip ---
...
0021:trace:typelib:QueryPathOfRegTypeLib
({00020430-0000-0000-c000-000000000046}, ffff.ffff, 0x0, 0x32d634)
0021:trace:reg:NtOpenKey
(0x21c,L"Typelib\\{00020430-0000-0000-C000-000000000046}",20019,0x32cfcc)
0021:trace:reg:NtOpenKey <- 0x22c
0021:trace:reg:RegEnumKeyExA
(0x22c,0,0x32cfd4,0x32cfd0(16),(nil),(nil),(nil),(nil))
0021:trace:ole:find_typelib_key found
L"Typelib\\{00020430-0000-0000-C000-000000000046}": 1.0
0021:trace:reg:RegEnumKeyExA
(0x22c,1,0x32cfd4,0x32cfd0(16),(nil),(nil),(nil),(nil))
0021:trace:ole:find_typelib_key found
L"Typelib\\{00020430-0000-0000-C000-000000000046}": 2.0
0021:trace:reg:RegEnumKeyExA
(0x22c,2,0x32cfd4,0x32cfd0(16),(nil),(nil),(nil),(nil))
0021:trace:ole:GetErrorInfo (0, 0x32cb70, (nil))
0021:trace:ole:CreateErrorInfo (0x32aab8)
0021:trace:ole:IErrorInfoImpl_QueryInterface (0x1d4110)->(
IID: {22f03340-547d-101b-8e65-08002b2bd119},0x32aab8)
0021:trace:ole:ICreateErrorInfoImpl_AddRef (0x1d4110)
0021:trace:ole:IErrorInfoImpl_AddRef (0x1d4110)->(count=1)
0021:trace:ole:IErrorInfoImpl_QueryInterface -- Interface:
(0x32aab8)->(0x1d4114)
0021:trace:ole:IErrorInfoImpl_Release (0x1d4110)->(count=2)
0021:trace:ole:ICreateErrorInfoImpl_SetDescription (0x1d4110): L"Type library
exporter encountered an error while processing 'SlingSDK'. Error: Common
Language Runtime Internal error: 0x8002801d"
0021:trace:ole:ICreateErrorInfoImpl_SetHelpFile (0x1d4110,L"complib.hlp")
0021:trace:ole:ICreateErrorInfoImpl_SetHelpContext (0x1d4110,4451)
0021:trace:ole:ICreateErrorInfoImpl_QueryInterface (0x1d4110)
0021:trace:ole:IErrorInfoImpl_QueryInterface (0x1d4110)->(
IID: {1cf2b120-547d-101b-8e65-08002b2bd119},0x32aab4)
0021:trace:ole:IErrorInfoImpl_AddRef (0x1d4110)->(count=1)
0021:trace:ole:IErrorInfoImpl_QueryInterface -- Interface:
(0x32aab4)->(0x1d4110)
0021:trace:ole:SetErrorInfo (0, 0x1d4110)
0021:trace:ole:IErrorInfoImpl_AddRef (0x1d4110)->(count=2)
0021:trace:ole:ICreateErrorInfoImpl_Release (0x1d4110)
0021:trace:ole:IErrorInfoImpl_Release (0x1d4110)->(count=3)
0021:trace:ole:IErrorInfoImpl_Release (0x1d4110)->(count=2)
0021:trace:ole:GetErrorInfo (0, 0x32cb3c, 0x1d4110)
0021:trace:ole:IErrorInfoImpl_GetSource (0x1d4110)->(pBstrSource=0x1d4298)
0021:trace:ole:IErrorInfoImpl_GetDescription
(0x1d4110)->(pBstrDescription=0x1d4294)
0021:trace:ole:IErrorInfoImpl_GetHelpFile (0x1d4110)->(pBstrHelpFile=0x1d429c)
0021:trace:ole:IErrorInfoImpl_GetHelpContext
(0x1d4110)->(pdwHelpContext=0x1d42a0)
0021:trace:ole:IErrorInfoImpl_GetGUID (0x1d4110)->(count=1)
0021:trace:ole:IErrorInfoImpl_Release (0x1d4110)->(count=1)
0021:trace:ole:IErrorInfoImpl_Release -- destroying IErrorInfo(0x1d4110)
0021:trace:seh:raise_exception code=e06d7363 flags=1 addr=0x7b8437e8
ip=0x7b84386b tid=0021
0021:trace:seh:raise_exception info[0]=19930520
0021:trace:seh:raise_exception info[1]=0032cb1c
0021:trace:seh:raise_exception info[2]=7a35d570
0021:trace:seh:raise_exception eax=7b82ca2d ebx=7b8c2bf8 ecx=00000000
edx=00004000 esi=00004000 edi=00000000
0021:trace:seh:raise_exception ebp=0032ca98 esp=0032ca34 cs=0023 ds=002b
es=002b fs=0063 gs=006b
--- snip ---
MSDN doesn't mention such condition so this obviously needs some test case to
find out what logic is used to select the best match (first? last? lowest?
highest?).
dll/oleaut32/typelib.c:find_typelib_key() needs to be fixed accordingly.
"wMaj" needs to be made an "out" parameter too to actually return best matching
maj.min pair
With this part fixed it goes further - only to stumble into next bug ;-)
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10467
Summary: Making Microsoft .NET 2.0 to work in wine, based on
example app FastMD5 1.4 for NET 2.0
Product: Wine
Version: CVS/GIT
Platform: PC
URL: http://www.paehl.de/english.php
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-dotnet
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Hello,
this bug id exists for the sole purpose of showing my little journey of getting
.NET 2.0 to work in wine.
This topic does *NOT* cover the MONO project in any way.
The windows version of MONO is covered by other bug reports.
DISCLAIMER: This is just a first step which aims at major show stoppers.
There are *many* issues left when it comes to managed (JIT) vs. unmanaged
(native) API code bridging.
To iron out all the bugs, many different applications are needed which cover
the whole range of .NET Framework.
I randomly chose a simple .NET 2.0 app which uses plain system.windows.forms
stuff (no fancy controls/interop).
--- snip ---
http://www.paehl.de/fastmd5_net20.zip
FASTMD5 create very fast with low CPU use a MD5 hash. Required .NET 1.1 or 2.0
--- snip ---
Just as foreword: yes, it plain sucks to debug mixed code in wine (managed +
unmanaged) because the tools required don't work reliable (or at all) due to
several wine bugs/design problems.
Prerequisite: successful installation of .NET 2.0 Framework and wine-0.9.49 (or
GIT)
----------
If you start .NET apps they will fail with stack overflows and some exceptions
thrown.
The exception type tells us what we are dealing with: 0xe0434f4d
For the uninitiated: this an exception type exclusively thrown by .NET common
language runtime (CLR).
Using my specially hacked wine to run tools like windbg one can get a raw
estimate by looking at native method callstack:
--- snip ---
0:000> sxe clr
..
0:000> .load clr20\sos.dll
..
0:000> g
..
0:000> kb
ChildEBP RetAddr Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
0034efb8 79f97065 e0434f4d 00000001 00000001 KERNEL32!RaiseException+0x78
0034f018 7a0945a4 00a11cb4 00000000 00000000
mscorwks!RaiseTheExceptionInternalOnly+0x226
0034f0dc 02fa364b 00000000 0000007f 0034f138 mscorwks!JIT_Throw+0xd0
0034f1d8 79e88f63 00000000 0012e0f8 0034f22c 0x2fa364b
0034f1f8 79e88f63 00000000 00000000 0016b200 mscorwks!CallDescrWorker+0x33
0034f210 79e88ee4 0034f2e8 00000002 0034f2b0 mscorwks!CallDescrWorker+0x33
..
--- snip ---
JIT code is at 0x2fa364b which transfers managed exceptions using
mscorwks!JIT_Throw() to native code/OS.
Lets look at CLR exception info...
--- snip ---
0:000> !PrintException
Exception object: 00a11cb4
Exception type: System.TypeInitializationException
Message: The type initializer for 'System.Globalization.TextInfo' threw an
exception.
InnerException: <none>
StackTrace (generated):
<none>
StackTraceString: <none>
HResult: 80131534
--- snip ---
And the managed code callstack...
--- snip ---
0:000> !ClrStack
OS Thread Id: 0xf (0)
ESP EIP
0034f040 7b8414d8 [HelperMethodFrame: 0034f040]
0034f0e4 02fa364b System.Globalization.TextInfo.GetNativeTextInfo(Int32)
0034f114 02fa3511 System.Globalization.TextInfo.get_InvariantNativeTextInfo()
0034f140 02fa193d System.String.Compare(System.String, Int32, System.String,
Int32, Int32, System.StringComparison)
0034f16c 02fa15a1
System.Security.Util.URLString.PreProcessForExtendedPathRemoval(System.String,
Boolean)
0034f184 02fa10b0 System.AppDomainSetup.NormalizePath(System.String, Boolean)
0034f1a4 02fa06d6
System.AppDomainSetup.SetupDefaultApplicationBase(System.String)
0034f1bc 02fa02cc System.AppDomain.SetupFusionStore(System.AppDomainSetup)
0034f1d4 02fa01fa System.AppDomain.SetupDomain(Boolean, System.String,
System.String)
0034f42c 79e88f63 [GCFrame: 0034f42c]
0034f9e0 79e88f63 [DebuggerClassInitMarkFrame: 0034f9e0]
--- snip ---
Some native method call in GetNativeTextInfo() seems to be the culprit.
For many (string) resource based stuff to work, a unicode OS casing table is
required.
The table for the invariant version is built from external .NLS file.
To make story short: wine does not ship the default case mapping table for
unicode characters: "l_intl.nls".
This is a "must" requirement and failure results in early
TypeInitializationException while setting up default application domain.
Short fix: copy the file from your windows system32 directory to wine system32.
Long run fix: let wine generate/install this file. Not a big deal.
Now simple .NET _console_ based apps (like "Hello World") will work.
---------------------------------------
Stay tuned, more goodies to come ...
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15437
Summary: Company of Heroes Opposing Fronts: Installer fails
Product: Wine
Version: 1.1.5
Platform: PC-x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: xvachon(a)gmail.com
Created an attachment (id=16303)
--> (http://bugs.winehq.org/attachment.cgi?id=16303)
log
Installation of the game is not possible. Exception EAccessViolation error in
module GameInst.exe happens. According to test data the game had to be
installed from a Windows installation in order to be played. A log is attached.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.