URL_ParseUrl FIXME messages on console when running/installing .NET apps are harmless and can be safely ignored. Example console output:

­­fixme:shell:URL_ParseUrl failed to parse L"mscorlib"

­Where "component" is one of ­the following:

• "IE5.01 or higher version is required"
• "Microsoft Windows Installer 3.0" is the requirement

Possible causes:

• inconsistent or broken WINEPREFIX (native overrides, services/device drivers). See Bug 16445 for such case.­
  
• wineboot problem (failed update of WINEPREFIX/timeout/permissions)
  

Solution:

First try to remove your old WINEPREFIX (rm -rf ~/.wine) and create a new o­ne by rerunning Winetricks .

If the problem persists, run wineboot manually:­

$ wineboot --update

­If you get a crash/backtrace like the following in console:

Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
at System.Drawing.SafeNativeMethods.Gdip.GdipCreateFontFromLogfontW(HandleRef hdc, Object lf, IntPtr& font)
at System.Drawing.Font.FromLogFont(Object lf, IntPtr hdc)
at System.Drawing.Font.FromHfont(IntPtr hfont)
at System.Drawing.SystemFonts.get_DefaultFont()
at System.Windows.Forms.Control.get_Font()
....

You most likely have a corrupted or non-conformant truetype font in your system. These are the most notorious ones:

­­/usr/share/fonts/truetype/arphic/ukai.ttf
/usr/share/fonts/truetype/ttf-oriya-fonts/Samyak-Oriya.ttf­

Method 1: Removal of fonts

Either remove that font files manually (not just renaming) or use your Linux package manager. On Ubuntu something like:

$ sudo apt-get remove ttf-oriya-fonts­

Make sure you use a recent version of winetricks script to make sure you get all font fixes required for .NET.

After winetricks script update, execute the following command in console (if you don't want to reinstall everything in new WINEPREFIX):

­$ sh winetricks fontfix

'winetricks fontfix' will install working versions of truetype fonts known as broken (like the notorious "ukai"). Don't worry, your original (broken) ones from your Linux distribution will be left unchanged. The "good" fonts get installed into Wine/Windows font directory which has higher font search path precedence - so the good ones will be pulled in when found before defaulting to Linux distribution ones.

If the application still crashes with the workarounds applied showing the above backtrace file a bug with bugzilla.

Reason #1

You used an old Wine version (< 1.1.7). Upgrade to Wine >= 1.1.7 which fixed this specific problem.

For Wine version < 1.1.7 use winetricks step:

$ wget http://kegel.com/wine/winetricks && sh winetricks volnum

Reason #2

This message can also result from installing into a broken WINEPREFIX. The following console message is an indication of a WINEPREFIX problem:

­err:process:__wine_kernel_init boot event wait timed out

Remove your WINEPREFIX and create a new one.

Some winetricks scripts install a newer version of "Samyak Oriya" meant as Linux system override for broken font version ('fontfix' step).

Because this updated font gets installed into "c:\\windows\\fonts" it will always be selected first when a requested font or substitute is not found (font path precedence enforces order in list).

This might cause garbage symbol display. To work around this, please remove the font "c:\\windows\\fonts\\Samyak-Oriya.ttf" if it exists.

Additionally make sure you update or remove the Samyak-Oriya font installed in your Linux Distribution. It often causes more harm than good when using native gdiplus (especially for .NET apps).

On Ubuntu something like:

$ sudo apt-get remove ttf-oriya-fonts­

Never run wine as root (su, sudo)! Wine doesn't require to be run as root!

You will screw your WINEPREFIX and possibly other things up. If you have run Wine as root you need to:

$ sudo rm -rf ~/.wine­

and then run winecfg to set Wine folder structure back up. If you used winetricks script as root you might also need to:

$ sudo rm -rf ~/winetrickscache

Again: Just run wine as regular user and all should be fine.

­This is Bug 9158 encountered in .NET Framework 3.0 web installer. Either use full (offline) installer (see download link) or the following workaround in console:­

$ _SFX_CAB_SHUTDOWN_REQUEST=1 wine ./vcssetup.exe

This is expected. The installer is minimized to systray (what's missing here is a balloon tooltip, indicating the action). Double click installer icon in systray to restore the dialog window.

If a .NET application exits with the following message in console:

fixme:shell:URL_ParseUrl failed to parse L"WindowsBase.resources"
fixme:advapi:ReportEventW (0xcafe4242,0x0001,0x0000,0x000003ff,(nil),0x0001,0x00000000,0x33b6e8,(nil)): stub ­
err:eventlog:ReportEventW L".NET Runtime version 2.0.50727.42 - Unrecoverable system error."
fixme:advapi:DeregisterEventSource (0xcafe4242) stub­

This 'Unrecoverable system error' is pretty general and can be caused by many things. For instance by bad truetype fonts. Some of Wine's truetype fonts are still not in shape of being a complete replacement for Windows ones, causing errors. You must use winetricks corefonts steps to work around this problem!

$ wget http://kegel.com/wine/winetricks

$ sh winetricks corefonts

The .NET 3.0 web installer detects Wine as Windows MUI with lots of language packs. Wine returns quite a number of supported user interface languages hence the installer tries to download a large number of .NET 3.0 language packs. This will later lead to problem because .NET 3.0 language packs require the corresponding .NET 2.0 language packs to be installed. These don't get automatically downloaded and installed which will lead to failure when the installer tries to install .NET 3.0 language packs.

Use the full (offline) installer (see download link). Be aware the full installer also has MUI (language packs) related problem, leading to large delay near the end of installation (see other note).

If you get an exception like this in console:

­$ wine ./foo.exe
...
fixme:shell:URL_ParseUrl failed to parse L"PresentationFramework"
fixme:shell:URL_ParseUrl failed to parse L"PresentationCore"
fixme:shell:URL_ParseUrl failed to parse L"System"
fixme:shell:URL_ParseUrl failed to parse L"WindowsBase"
fixme:advapi:RegisterTraceGuidsW 0x7f0542 (nil) 0x32dfd0 1 0x32dfac (null) (null) 0x32dfb4
fixme:advapi:RegisterTraceGuidsW 0x532dc234 (nil) 0x53218780 27 0x32ccf8 (null) (null) 0x53355f40
fixme:seh:RtlCaptureStackBackTrace (2, 3, 0x533546cc, (nil)) stub!­
wine: Call from 0x7b84303a to unimplemented function windowscodecs.dll.WICCreateImagingFactory_Proxy, aborting

Please use native override for windowscodecs component (winecfg) and set it to "native" (NOT "native then builtin").

Wine's WIC isn't mature enough at this point.

The .NET 3.0 full (offline) installer detects Wine as Windows MUI with lots of language packs. Wine returns quite a number of supported user interface languages. When it comes to language pack stage there is an installer builtin polling period of 30 seconds for the presence of each language pack file on disk. Because language pack files are not present in offline install, the full period is used - adding up this large delay near the end of installation (spanning several minutes).

Note: Even if you put all the requested language packs into the appropriate folder it won't work due missing .NET 2.0 language packs (which are not automatically installed).

If you don't want to wait for several minutes until the installer actually finishes, you can either:

1. Update winetricks to version >= 20100201 which includes the workaround

or

2. Use the following script before running the .NET 3.0 installer:

­#! /bin/bash

WINEPREFIX=${WINEPREFIX:-$HOME/.wine}

LANGPACKS_BASE_PATH="${WINEPREFIX}/drive_c/windows/SYSMSICache/Framework/v3.0"

[[ -d "${WINEPREFIX}" ]] || wineboot --init

[[ -d "${LANGPACKS_BASE_PATH}" ]] || mkdir -p "${LANGPACKS_BASE_PATH}"

LANGPACKS=( "jp" "de" "fr" "es" "it" "zh-CHT" "zh-CHS" "ko" "ar" "pt-BR" "pt-PT" \
        "cs" "da" "nb" "nl" "fi" "el" "he" "pl" "ru" "sv" "tr")

for lang in "${LANGPACKS[@]}"
do
   ln -s "${WINEPREFIX}/drive_c/windows/system32/spupdsvc.exe" "${LANGPACKS_BASE_PATH}/dotnetfx3langpack${lang}.exe"
done ­

What does it do?

This script basically creates "fake" language pack files by symlinking to some executable that will be created during install process. The reason why this executable was chosen: it has to contain digital signature and return process exit code "0" regardless what command line parameters are passed.

The console windows popping up while calling "fake" language pack installer are harmless because the executable is flagged as console program.

Make sure you operate on a clean WINEPREFIX (~/.wine)!

­You need at least Wine version >= 1.1.27 for installation!­­

Installation by using 'winetricks' script

Winetricks will take care of all needed installation prerequisites and work around some problems.­

$ wget http://kegel.com/wine/winetricks

.NET Framework 2.0 Redistributables installation is needed as prerequisite:
­

$ sh winetricks dotnet20

Use the following winetricks verb to automatically download and install .NET 3.0 Framework:

­$ sh winetricks dotnet30

Be patient until it finishes.

.Net 3.0 SP1 full (offline) installer will currently not work due to several bugs. This blog gives some hints: installing-net-framework-30-sp1-on

Basically working installations of .NET 2.0 Framework Service Pack 1 and XPSEPSC component are required as prerequisite.

­This is bug 18640 (Wine D3D9 insufficiency). The following console messages are an indication of the problem:

­fixme:d3d9:IDirect3D9ExImpl_GetAdapterLUID (0x17b328)->(0, 0x1814d0)
fixme:d3d9:IDirect3D9ExImpl_GetAdapterDisplayModeEx (0x17b328)->(0, 0x181568, 0x181580): Stub!
fixme:seh:RtlCaptureStackBackTrace (2, 3, 0x533546e4, (nil)) stub!
...
err:ntdll:vDbgPrintExW­ithPrefix 65: MIL FAILURE: Unexpected HRESULT 0x88760827 in caller:­ Could not create display set. fixme:d3d9:IDirect3D9ExImpl_GetAdapterLUID (0x17a388)->(0, 0x19bc­c0)
fixme:d3d9:IDirect3D9ExImpl_GetAdapterDisplayModeEx (0x17a388)->(0, 0x19bd58, 0x19bd70): Stub!
fixme:seh:RtlCaptureStackBackTrace (2, 3, 0x533547a4, (nil)) stub!
err:ntdll:vDbgPrintExWithPrefix 65: MIL FAILURE: Unexpected HRESULT 0x88760827 in caller: The render thread failed unexpectedly.
fixme:seh:RtlCaptureStackBackTrace (2, 3, 0x533548ac, (nil)) stub!
...
fixme:shell:URL_ParseUrl failed to parse L"PresentationFramework.resources"
...
fixme:advapi:RegisterEventSourceW ((null),L".NET Runtime 2.0 Error Reporting"): stub
fixme:advapi:ReportEventW (0xcafe4242,0x0001,0x0000,0x00001388,(nil),0x000b,0x00000102,0x3009a1b4,0x6cc5c4): stub

Temporary Workaround:

Currently the workaround is to force WPF's milcore to fall back to GDI renderer using the following command (effectively disabling d3d9):

$ WINEDLLOVERRIDES="d3d9=""" wine ./foo.exe

­Note: Most .NET 3.x GUI apps will still not work due to ­insufficiencies in Wine!

­If you get the following backtrace in WPF enabled app with fallback renderer (see ".NET 3.x GUI apps perform badly or crash due to Wine D3D9 stubs (functionality needed by Windows Presentation Framework" note how to use it):

­Unhandled Exception: System.InvalidOperationException: An unspecified error occurred on the render thread.
   at System.Windows.Media.MediaContext.NotifyPartitionIsZombie(Int32 failureCode)
   at System.Windows.Media.MediaContext.NotifyChannelMessage()
   at System.Windows.Interop.HwndTarget.HandleMessage(Int32 msg, IntPtr wparam, IntPtr lparam)
   at System.Windows.Interop.HwndSource.HwndTargetFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Boolean isSingleParameter)
   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Boolean isSingleParameter, Delegate catchHandler)
   at System.Windows.Threading.Dispatcher.InvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Boolean isSingleParameter)
   at System.Windows.Threading.Dispatcher.Invoke(DispatcherPriority priority, Delegate method, Object arg)
   at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
   at MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg)
   at System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame)
   at System.Windows.Threading.Dispatcher.PushFrame(DispatcherFrame frame)
   at System.Windows.Threading.Dispatcher.Run()
   at System.Windows.Application.RunInternal(Window window)
   at System.Windows.Application.Run(Window window)
   at System.Windows.Application.Run()

.NET 3.x WPF uses two threads: the UI thread and the render thread. When the render thread encounters a failure, it notifies the UI thread, which throws an InvalidOperationException from MediaContext.NotifyPartitionIsZombie. Unfortunately the stack of the UI thread is completely unrelated to the stack of the render thread when it failed which makes it difficult to track down the real cause.

Some crashes result from bugs in layered windows support which are fixed in the .Net Framework 3.5 SP1. Other causes can be video drivers or 3rd party software hooking specific gfx API, interfering with .NET's WPF.