http://bugs.winehq.org/show_bug.cgi?id=27796
Summary: JDK 6 installer fails with error "File name is too
long"
Product: Wine
Version: unspecified
Platform: x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: gabspeck(a)gmail.com
Created an attachment (id=35559)
--> (http://bugs.winehq.org/attachment.cgi?id=35559)
The error message
Running the Oracle JDK 6u26 installer on Wine results in the following error
message being displayed: "Installer : Wrapper.CrateFile failed with error 206:
File name is too long".
--
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=24214
Summary: ole: Java SE JRE subinstaller (msi) dies due to OLE
compound storage reader failure on some stream (the
one after _StringPool stream)
Product: Wine
Version: 1.1.21
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: ole
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Hello,
when installing Java SE JRE one of the sub-installers crashes.
Though it doesn't seem to affect overall installer result - the installer still
reports "success" in the end.
--- snip ---
...
0009:Call KERNEL32.CreateProcessA(00000000,0032ed40
"\"C:\\windows\\system32\\msiexec.exe\" /i \"C:\\users\\focht\\Application
Data\\Sun\\Java\\jdk1.6.0_21\\jdk1.6.0_21.msi\"
WRAPPER=1",00000000,00000000,00000000,00000000,00000000,00000000,0032c4d0,0032c514)
ret=00401184
....
001d:trace:msi:ACTION_ProcessComponents Component L"sb160210"
(L"14888323ADFE6D117AD8000B0D612001"), Keypath=L"C:\\Program
Files\\Java\\jdk1.6.0_21\\javadb.msi", RefCount=1 Request=3
...
001d:trace:msi:MSI_ProcessMessage (nil) (nil) (nil) 0 200 L"File: javadb.msi,
Directory: INSTALLDIR, Size: 10566952"
...
001d:trace:msi:cabinet_copy_file extracting L"C:\\Program
Files\\Java\\jdk1.6.0_21\\javadb.msi"
001d:Call KERNEL32.CreateFileW(00205320 L"C:\\Program
Files\\Java\\jdk1.6.0_21\\javadb.msi",c0000000,00000000,00000000,00000002,00000080,00000000)
ret=683a75f4
001d:Ret KERNEL32.CreateFileW() retval=00000054 ret=683a75f4
...
001d:trace:msi:ACTION_CustomAction Handling custom action L"installjavadb" (62
L"SystemFolder" L"msiexec.exe /i \"[INSTALLDIR]javadb.msi\" /qn
INSTALLDIR=\"[JAVADB_DIR]\"")
...
001d:trace:msi:HANDLE_CustomType34 executing exe L"msiexec.exe /i \"C:\\Program
Files\\Java\\jdk1.6.0_21\\javadb.msi\" /qn INSTALLDIR=\"C:\\Program
Files\\Sun\\JavaDB\\\"" with working directory L"C:\\windows\\system32\\"
...
000d:Call msi.MsiInstallProductW(0013914e L"C:\\Program
Files\\Java\\jdk1.6.0_21\\javadb.msi",00139270 L" INSTALLDIR=\"C:\\Program
Files\\Sun\\JavaDB\\\"") ret=6833da64
000d:trace:msi:MsiInstallProductW L"C:\\Program
Files\\Java\\jdk1.6.0_21\\javadb.msi" L" INSTALLDIR=\"C:\\Program
Files\\Sun\\JavaDB\\\""
000d:trace:msi:MSI_OpenPackageW L"C:\\Program
Files\\Java\\jdk1.6.0_21\\javadb.msi" 0x33fc1c
...
000d:Call KERNEL32.CopyFileW(0013914e L"C:\\Program
Files\\Java\\jdk1.6.0_21\\javadb.msi",0033f9b8
L"C:\\users\\focht\\Temp\\msi58c.tmp",00000000) ret=683b95ab
...
000d:trace:msi:MSI_OpenPackageW Opening relocated package
L"C:\\users\\focht\\Temp\\msi58c.tmp"
000d:trace:msi:MSI_OpenDatabaseW L"C:\\users\\focht\\Temp\\msi58c.tmp" #0002
000d:Call ole32.StgOpenStorage(0033f9b8
L"C:\\users\\focht\\Temp\\msi58c.tmp",00000000,00000012,00000000,00000000,0033f11c)
ret=683880da
000d:Call KERNEL32.CreateFileW(0033f9b8
L"C:\\users\\focht\\Temp\\msi58c.tmp",c0000000,00000000,00000000,00000003,10000080,00000000)
ret=684f87b9
000d:Ret KERNEL32.CreateFileW() retval=00000040 ret=684f87b9
000d:Call KERNEL32.GetFileSize(00000040,00000000) ret=684f87dd
000d:Ret KERNEL32.GetFileSize() retval=00a13d28 ret=684f87dd
...
000d:trace:msidb:enum_stream_names stream 0 -> L"\4840\430f\422f" L"\4840File"
...
000d:trace:msidb:enum_stream_names stream 41 -> L"\0005SummaryInformation"
L"\0005SummaryInformation"
...
000d:trace:msidb:read_stream_data L"_StringPool" ->
L"\4840\3f3f\4577\446c\3e6a\44b2\482f"
...
000d:warn:msidb:read_stream_data read stream failed r = 8003001e!
...
000d:trace:seh:raise_exception code=c0000005 flags=0 addr=0x683d2c6b
ip=683d2c6b tid=000d
000d:trace:seh:raise_exception info[0]=00000000
000d:trace:seh:raise_exception info[1]=00000000
000d:trace:seh:raise_exception eax=00000000 ebx=68400df8 ecx=00000000
edx=00000000 esi=001408dc edi=00000000
000d:trace:seh:raise_exception ebp=0033edf8 esp=0033ede0 cs=0023 ds=002b
es=002b fs=0063 gs=006b flags=00010202
000d:trace:seh:call_vectored_handlers calling handler at 0x68c622d0
code=c0000005 flags=0
000d:trace:seh:call_vectored_handlers handler at 0x68c622d0 returned 0
000d:trace:seh:call_stack_handlers calling handler at 0x7bc856a0 code=c0000005
flags=0
000d:Call KERNEL32.UnhandledExceptionFilter(0033e92c) ret=7bc856ed
Wine: Unhandled page fault on read access to 0x00000000 at address 0x683d2c6b
(thread 000d), starting debugger...
000d:trace:seh:start_debugger Starting debugger "winedbg --auto 11 68"
...
---- snip ---
Using "orca" on the extracted .msi produces the same crash.
The useful "MsiInfo" tool from Platform SDK to verify the integrity of the .msi
files (and dump infos) crashes too if used with no options.
Backtrace doesn't reveal much. The fault caused in msi_destroy_stringtable() is
the result of an earlier failure to read in all OLE streams properly.
When the "verify string pool" option is used, it doesn't crash but shows the
STG_E_READFAULT (0x8003001e) error.
--- snip ---
$ wine msiinfo.exe crash.msi /D
MsiInfo V 4.0
Copyright (c) Microsoft Corporation. All Rights Reserved
String ID size: 2
Code page: 0
Error 0x8003001E. Error Reading Stream
err:ole:CoUninitialize Mismatched CoUninitialize
--- snip ---
--- snip ---
ls -l crash.msi
-rw-rw-r--. 1 focht focht 10566952 2010-08-30 21:52 crash.msi
--- snip ---
>From my investigation it's the stream directly after "_StringPool" stream that
is somehow not processed properly.
Wine's OLE streams reader makes a stream access at file offset 10566656 with
byte count 512 -> past end of file.
You can use another OLE compound storage viewer to verify:
http://www.mitec.cz/ssv.html
It's a nice tool with plugin arch that lets you decode any OLE stream - if you
write plugins for it ;-)
If you open the .msi with the viewer it reports "sharing violation" which is
another Wine bug.
Dismiss the dialog and navigate the treeview with all streams listed.
Between stream #22 with 90701 Bytes (-> _StringPool stream) and #24 with 3984
bytes the 0x8003001e error appears.
The "faulty" stream #23 has a size of 16168 bytes.
Don't know if this worked in earlier Wine versions, could be a regression
though.
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=25362
Summary: Error running Return to Castle Wolfenstein
Product: WineHQ Apps Database
Version: unspecified
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: appdb-unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: mrfort(a)centurytel.net
Created an attachment (id=32259)
--> (http://bugs.winehq.org/attachment.cgi?id=32259)
debugger report
Installed ok. Allowed setup preferences such as graphics and audio preferences.
When I try to run in single player I get this error: Error in file
"/home/name/.local/share/applications/clamtk.desktop": "vms/exe" is an invalid
MIME type ("vms" is an unregistered media type).
I assume it is an easy fix but cannot locate any information online or in your
repository.
--
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=25120
Summary: dotnet11 installation broken
Product: Wine
Version: 1.3.6
Platform: x86
OS/Version: Linux
Status: NEW
Keywords: dotnet, download, Installer
Severity: normal
Priority: P2
Component: msi
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: austinenglish(a)gmail.com
Created an attachment (id=31862)
--> (http://bugs.winehq.org/attachment.cgi?id=31862)
terminal output
Regression test points to:
a23514eece083011140513853c5db10357af6cea is the first bad commit
commit a23514eece083011140513853c5db10357af6cea
Author: Hans Leidekker <hans(a)codeweavers.com>
Date: Thu Nov 11 10:45:42 2010 +0100
msi: Add support for installing side-by-side assemblies.
:040000 040000 6e3244306b1cdce4af9bd963048445913433d933
820db510d39486aa37cad45d1ebeb9e2397f6224 M dlls
to repeat:
$ rm -rf ~/.wine
$ sh winetricks -q -v winetricks
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=26701
Summary: exeinfoPE crashes due to PE resource section
validation being too strict
Product: Wine
Version: 1.3.17
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: ntdll
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Hello,
while updating some appdb entries I noticed a breakage with some PE "id" tool.
The app worked some time ago but now crashes instantly.
There was a minor version update: the author probably not only added more
signatures but tweaked the custom PE protection the app is wrapped with.
--- snip ---
>$ wine ./exeinfoPE.exe
wine: Unhandled exception 0x0eedfade at address 0x7b83983a:0x7b83863f (thread
0009), starting debugger...
fixme:dbghelp_dwarf:dwarf2_lookup_type Unable to load forward reference for tag
26
fixme:dbghelp_dwarf:dwarf2_lookup_type Unable to load forward reference for tag
26
fixme:dbghelp_dwarf:dwarf2_lookup_type Unable to load forward reference for tag
26
err:seh:setup_exception_record stack overflow 880 bytes in thread 0009 eip
6816b5ea esp 00230fc0 stack 0x230000-0x231000-0x330000
--- snip ---
relay trace yields following:
--- snip ---
...
0021:Call KERNEL32.FindResourceA(00400000,00472384 "tbl_Main",0000000a)
ret=00474417
0021:trace:resource:FindResourceExA 0x400000 #000a "tbl_Main" 0000
0021:trace:resource:LdrFindResource_U module 0x400000 type #000a name
L"TBL_MAIN" lang 0000 level 3
0021:Ret KERNEL32.FindResourceA() retval=00000000 ret=00474417
0021:Call user32.LoadStringA(00400000,0000ffc3,0032ed34,00001000) ret=00407417
0021:trace:resource:LoadStringA instance = 0x400000, id = ffc3, buffer =
0x32ed34, length = 4096
0021:trace:resource:FindResourceExW 0x400000 #0006 #0ffd 0000
0021:trace:resource:LdrFindResource_U module 0x400000 type #0006 name #0ffd
lang 0000 level 3
0021:trace:resource:LoadStringA returning ""
0021:Ret user32.LoadStringA() retval=00000000 ret=00407417
0021:Call KERNEL32.RaiseException(0eedfade,00000001,00000007,0032fd7c)
ret=0047444b
0021:trace:seh:raise_exception code=eedfade flags=1 addr=0x7b83863f ip=7b83863f
tid=0021
0021:trace:seh:raise_exception info[0]=0047444b
0021:trace:seh:raise_exception info[1]=05701d10
0021:trace:seh:raise_exception info[2]=0053a9e0
0021:trace:seh:raise_exception info[3]=00000000
0021:trace:seh:raise_exception info[4]=00000029
0021:trace:seh:raise_exception info[5]=0032fde8
0021:trace:seh:raise_exception info[6]=0032fd98
0021:trace:seh:raise_exception eax=7b825a75 ebx=7b88fff4 ecx=0047444b
edx=0032fc94 esi=0032fd7c edi=0032fcf0
0021:trace:seh:raise_exception ebp=0032fcd8 esp=0032fc74 cs=0073 ds=007b
es=007b fs=0033 gs=003b flags=00000203
0021:trace:seh:call_vectored_handlers calling handler at 0x788636c6
code=eedfade flags=1
0021:trace:seh:call_vectored_handlers handler at 0x788636c6 returned 0
0021:trace:seh:call_stack_handlers calling handler at 0x474573 code=eedfade
flags=1
0021:trace:seh:call_stack_handlers handler at 0x474573 returned 1
0021:trace:seh:call_stack_handlers calling handler at 0x405149 code=eedfade
flags=1
...
--- snip ---
The app unpacks/decrypts PE sections into dynamic memory and patches the PE
header to point to new locations.
I dumped the PE header at the right place ;-)
--- snip ---
Wine-dbg>p *nt
{Signature=0x4550, FileHeader={Machine=0x14c, NumberOfSections=0x3,
TimeDateStamp=0x2a425e19, PointerToSymbolTable=0, NumberOfSymbols=0,
SizeOfOptionalHeader=0xe0, Characteristics=0x818f},
OptionalHeader={Magic=0x10b, MajorLinkerVersion=2, MinorLinkerVersion=0,
SizeOfCode=0x8c000, SizeOfInitializedData=0x5000,
SizeOfUninitializedData=0x513a000, AddressOfEntryPoint=0x51c5810,
BaseOfCode=0x513b000, BaseOfData=0x51c7000, ImageBase=0x400000,
SectionAlignment=0x1000, FileAlignment=0x200, MajorOperatingSystemVersion=0x4,
MinorOperatingSystemVersion=0, MajorImageVersion=0, MinorImageVersion=0,
MajorSubsystemVersion=0x4, MinorSubsystemVersion=0, Win32VersionValue=0,
SizeOfImage=0x51cc000, SizeOfHeaders=0x1000, CheckSum=0x51c5810, Subsystem=0x2,
DllCharacteristics=0, SizeOfStackReserve=0x100000, SizeOfStackCommit=0x4000,
SizeOfHeapReserve=0x100000, SizeOfHeapCommit=0x1000, LoaderFlags=0,
NumberOfRvaAndSizes=0x12, DataDirectory={{VirtualAddress=0x5159000, Size=0x4f},
{VirtualAddress=0x51cb120, Size=0x2c8}, {VirtualAddress=0x51c7000, Size=0},
{VirtualAddress=0, Size=0}, {VirtualAddress=0, Size=0}, {VirtualAddress=0,
Size=0}, {VirtualAddress=0, Size=0}, {VirtualAddress=0, Size=0},
{VirtualAddress=0, Size=0}, {VirtualAddress=0x51c63b0, Size=0x18},
{VirtualAddress=0, Size=0}, {VirtualAddress=0, Size=0}, {VirtualAddress=0,
Size=0}, {VirtualAddress=0, Size=0}, {VirtualAddress=0, Size=0},
{VirtualAddress=0, Size=0}}}}
--- snip ---
The (new) PE resource section is located at 0x051c7000 with size == 0 (not
recalculated to real value)
Wine's resource directory entry size check is actually the problem, preventing
the app from finding its resources.
--- snip ntdll/resource.c ---
/**********************************************************************
* find_entry
*
* Find a resource entry
*/
static NTSTATUS find_entry( HMODULE hmod, const LDR_RESOURCE_INFO *info,
ULONG level, const void **ret, int want_dir )
{
ULONG size;
const void *root;
const IMAGE_RESOURCE_DIRECTORY *resdirptr;
WORD list[9]; /* list of languages to try */
int i, pos = 0;
root = RtlImageDirectoryEntryToData( hmod, TRUE,
IMAGE_DIRECTORY_ENTRY_RESOURCE, &size );
if (!root) return STATUS_RESOURCE_DATA_NOT_FOUND;
if (size < sizeof(*resdirptr)) return STATUS_RESOURCE_DATA_NOT_FOUND;
resdirptr = root;
...
--- snip ntdll/resource.c ---
This also results in stack overflow because the app's exception handler tries
to load resources too which obviously fails.
Removing the size check (size < sizeof(*resdirptr)) lets the app successfully
start.
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=15549
Summary: Colobot Demo installer does not fully redraw
installation window during install progress phase
Product: Wine
Version: 1.1.5
Platform: PC
URL: http://www.ceebot.com/download/demo/colobotdemo17e.exe
OS/Version: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: nodisgod(a)yahoo.com
Created an attachment (id=16531)
--> (http://bugs.winehq.org/attachment.cgi?id=16531)
Colobot Demo installer window screenshot
With today's Git (wine-1.1.5-507-ge20ef50), in the process of testing bug
13932, I noticed that when the installer is at the file copy progress phase,
some elements of the window are not redrawn properly. A screenshot 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.
http://bugs.winehq.org/show_bug.cgi?id=23847
Summary: ntdll:
NtQuerySystemInformation(SYSTEM_PROCESSOR_PERFORMANCE_
INFORMATION) should provide NT-style 100ns units (.NET
1.x CLR)
Product: Wine
Version: 1.3.0
Platform: x86
URL: http://www.microsoft.com/DownLoads/details.aspx?family
id=D7158DEE-A83F-4E21-B05A-009D06457787
OS/Version: Linux
Status: NEW
Keywords: dotnet, download, Installer
Severity: normal
Priority: P2
Component: ntdll
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Hello,
after bug 17084 (.NET 1.0: imagehlp.ImageGetDigestStream needs more flesh
(assembly registration fails)) was fixed, the installer still fails.
The first blocker is now the presence of some .NET registry keys that ought to
help Mono but break the MS installer itself (path to v1.0.xxx Microsoft CLR
core library is incorrectly constructed, leading to mscorwks.dll load failure).
You can work around by deleting the following key before running the installer:
--- snip ---
$ wine reg delete "HKLM\Software\Microsoft\.NETFramework"
--- snip ---
Near the end, the installer spawns "regasm.exe" tool several times to register
various assemblies.
Unfortunately the tool crashes with division by zero (+tid,+seh,+relay):
--- snip ---
...
0040:Call ntdll.NtQuerySystemInformation(00000008,031ce960,00000060,00000000)
ret=792cf160
0040:Ret ntdll.NtQuerySystemInformation() retval=00000000 ret=792cf160
0040:trace:seh:raise_exception code=c0000094 flags=0 addr=0x79243177
ip=79243177 tid=0040
0040:trace:seh:raise_exception eax=00000000 ebx=ffffffff ecx=00000000
edx=00000000 esi=00000022 edi=00000001
0040:trace:seh:raise_exception ebp=031ce9f0 esp=031ce940 cs=0023 ds=002b
es=002b fs=0063 gs=006b flags=00010246
--- snip ---
Interestingly there are other calls from the same addresses that don't crash:
--- snip ---
0020:Call ntdll.NtQuerySystemInformation(00000008,0320e960,00000060,00000000)
ret=792cf160
0020:trace:ntdll:NtQuerySystemInformation
(0x00000008,0x320e960,0x00000060,(nil))
000d:Call KERNEL32.SwitchToThread() ret=7929a604
000d:Ret KERNEL32.SwitchToThread() retval=00000001 ret=7929a604
0020:Ret ntdll.NtQuerySystemInformation() retval=00000000 ret=792cf160
0020:Call KERNEL32.Sleep(000001f4) ret=792d00bc
--- snip ---
Using additional "printf" style debugging to dump kernel+user+idle jiffies I
noticed the crashes happen when the values accumulated only small changes in
capture intervals.
It seems the CLR employs some kind of cpu resource utilization calculation
(using certain capture intervals) that breaks if the ticks/time units increment
fall below some threshold.
Windows NT accounts SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION values in 100ns
units.
See: http://msdn.microsoft.com/en-us/library/ms724509.aspx
I fixed dlls/ntdll/nt.c:NtQuerySystemInformation(
SystemProcessorPerformanceInformation class) to convert jiffies to NT-style
100-ns units and it helped to keep the .NET CLR CPU usage calculation happy and
to not let the regasm tool crash anymore (installer succeeded).
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.