Running an .NET 1.1 Program

[MasterTH]

Hello,

im trying to run an .NET 1.1 Program. .NET V1.1 Installation works fine, but when i want to start the Program i get some errors and Program exits

Code: Select all

fixme:virtual:NtAllocateVirtualMemory MEM_WRITE_WATCH type not supported
fixme:virtual:NtAllocateVirtualMemory MEM_WRITE_WATCH type not supported
fixme:shell:URL_ParseUrl failed to parse L"mscorlib"
fixme:shell:URL_ParseUrl failed to parse L"System.Data"

Maybe this is an known bug or someone has a workthru for me.


Thanks a lot


NOTE: I'm using Wine in version 0.9.57 the latest stable release.

[James McKenzie]

MasterTH wrote:

Hello,

im trying to run an .NET 1.1 Program. .NET V1.1 Installation works fine, but when i want to start the Program i get some errors and Program exits


Code:

fixme:virtual:NtAllocateVirtualMemory MEM_WRITE_WATCH type not supported
fixme:virtual:NtAllocateVirtualMemory MEM_WRITE_WATCH type not supported
fixmeURL_ParseUrl failed to parse L"mscorlib"
Application tried to create a window, but no driver could be loaded.
Make sure that your X server is running and that $DISPLAY is set correctly.
Application tried to create a window, but no driver could be loaded.
Make sure that your X server is running and that $DISPLAY is set correctly.
err:ole:apartment_createwindowifneeded CreateWindow failed with error 1114
fixmeURL_ParseUrl failed to parse L"System.Data"

What program are you trying to run? I am assuming that you are using
version 0.9.57 of Wine as well.

James McKenzie

[MasterTH]

i'm working in a government. It's SD.NET Nobody would know about it

Code: Select all

linux-c5xy:~ # wine --version
wine-0.9.57

I have installed the .NET Framework 1.1 & 2.0
The windows version of Mono 1.9 is also installed.

[Plamen.Vassilev]

Are you trying to run wine as root? If this is the case, then don't!
Also it seems that either you have not a running instance of X server, or probably you have it running for another user. For example you are logged as user Joe, and in the graphical environment you started console, made yourself root there and trying to start wine as root.

Please, try running wine again as regular user, and report back.

regards
Plamen

[MasterTH]

when i'm running this on the lokal desktop the same error appears.


running this with user privilegs is the next thing:

[Dan Kegel]

On Wed, Mar 19, 2008 at 7:07 AM, MasterTH <[email protected]> wrote:

when i'm running this on the lokal desktop the same error appears.

running this with user privilegs is the next thing:

I'm tempted to say wait until Wine officially supports .net 1.1...
- Dan

[MasterTH]

ok,

is it on the roadmap already??

[Dan Kegel]

On Wed, Mar 19, 2008 at 8:25 AM, MasterTH <[email protected]> wrote:

is it on the roadmap already??

There isn't any roadmap per se, but I do know that
we get a steady stream of excellent bug reports
with workarounds, so once we catch up with
the guy who's submitting them, it will probably
handle at least simple apps.

[James McKenzie]

MasterTH wrote:

i'm working in a government. It's SD.NET Nobody would know about it

I understand. Is this code available somewhere?

Code:

linux-c5xy:~ # wine --version
wine-0.9.57

This looks good.

If the program is not available to the public, then try another .NET 1.1
program that is and see if the error can be reproduced. If we cannot
test the program to find the bug, we cannot hope to fix it.

James McKenzie

[MasterTH]

Good Morning from germany,

sorry code is not availible anywhere.

But i tried a different program with uses the .NET Framework 1.1. Here is the Link
http://www.winload.de/screenshots/41122 ... T.1.6.html

Installation works fine, after starting the Program the same crash appears. With an other .NET DLL but i think the problem is the same.


Here's the console output:

Code: Select all

fixme:virtual:NtAllocateVirtualMemory MEM_WRITE_WATCH type not supported
fixme:virtual:NtAllocateVirtualMemory MEM_WRITE_WATCH type not supported
fixme:shell:URL_ParseUrl failed to parse L"mscorlib"
fixme:shell:URL_ParseUrl failed to parse L"System.Windows.Forms"

[MasterTH]

i dont know a lot what happens in the installation progress of the .NET Framework, but it seems that the problem is the registration of the .NET-Modules.

When coding an .NET program you use this System-Variables

Like:
Import System.Data

[Dan Kegel]

On Wed, Mar 19, 2008 at 11:39 PM, MasterTH <[email protected]> wrote:

But i tried a different program with uses the .NET Framework 1.1. Here is the Link
http://www.winload.de/screenshots/41122 ... T.1.6.html

Installation works fine, after starting the Program the same crash appears.

fixme:virtual:NtAllocateVirtualMemory MEM_WRITE_WATCH type not supported
fixmeURL_ParseUrl failed to parse L"mscorlib"
fixmeURL_ParseUrl failed to parse L"System.Windows.Forms"

Like I said, you probably want to wait until .net is
better supported in Wine. It's not likely to make
you happy yet.
- Dan

[MasterTH]

James McKenzie wants to know if there is another .NET program with the same bug for testing

MasterTH wrote:
Quote:
i'm working in a government. It's SD.NET Nobody would know about it


I understand. Is this code available somewhere?
Quote:
Code:

linux-c5xy:~ # wine --version
wine-0.9.57


This looks good.

If the program is not available to the public, then try another .NET 1.1
program that is and see if the error can be reproduced. If we cannot
test the program to find the bug, we cannot hope to fix it.

James McKenzie

[Hugo Cardozo]

El Jueves, 20 de Marzo de 2008 07:41, MasterTH escribió:

James McKenzie wants to know if there is another .NET program with the same
bug for testing

This looks good.

If the program is not available to the public, then try another .NET 1.1
program that is and see if the error can be reproduced. If we cannot
test the program to find the bug, we cannot hope to fix it.

James McKenzie

I tried the CASE software GeneXus (the trial version). It installed fine, but
it crashed when I tried to create an "object". The error was the same:

fixme:virtual:NtAllocateVirtualMemory MEM_WRITE_WATCH type not supported

BTW, I couldn't install .NET 1.1, so I installed .NET 2 . But GeneXus works
with at least .NET 1.1

Hugo S.

[Timeout]

fixme:virtual:NtAllocateVirtualMemory MEM_WRITE_WATCH type not supported

is probably NOT the reason for the crash.

I have it too on my .NET application and I can safely ignore it because the application is not affected.

If you read some documentation about the net, you will see that the .NET is using JIT and not MEM_WRITE_WATCH but MEM_WRITE_WATCH is used by Visual Basic which leads me to the (uneducated) opinion that this error is just thrown by the C++ on which the .NET is based.
However as per WINDOWS_2000 if MEM_WRITE_WATCH is not supported, it is just ignored by the concerned components.

Please do not fire on me if there is a mistake in what I said

Edit: I have my own view about the .NET not working well, especially after I had been asked to test the new Winetrick for the .NET.
The .NET is working well on my hacked GIT (version for version I am removing 3 lines added in 0.9.49).
However once I had been asked to test the winetrick, I made another user (not to affect my existing .NET application on my prefix) and installed using a packaged Wine for my distribution.
There I had for my surprise a stack overflow using the components to my other installed hacked Wine (on GIT).
This lead me to the conclusion that the .NET had installed files on my tmp, the new installation of the .NET had found this files because the tmp is shared between the users, tried to used them and had a stack overflow because of the wrong user.
From what I heard, .NET not working is affecting more Suse and Fedora and Ubuntu seems OK.
If Ubuntu has the tmp directory as the user and not Fedora and surely not SUSE (although there seem to be work in this way for the new SUSE since the user is installed before root on a new installation) this push me to the conclusion that for the next months the .NET working will be more an exception than the rule.

[James McKenzie]

MasterTH wrote:

Good Morning from germany,

sorry code is not availible anywhere.

But i tried a different program with uses the .NET Framework 1.1. Here is the Link
http://www.winload.de/screenshots/41122 ... T.1.6.html

Installation works fine, after starting the Program the same crash appears. With an other .NET DLL but i think the problem is the same.


Here's the console output:

Code:


fixme:virtual:NtAllocateVirtualMemory MEM_WRITE_WATCH type not supported
fixme:virtual:NtAllocateVirtualMemory MEM_WRITE_WATCH type not supported
fixmeURL_ParseUrl failed to parse L"mscorlib"
fixmeURL_ParseUrl failed to parse L"System.Windows.Forms"

Thank you. I will look at this along with the program I have been
working with which likes .NET 1.1 support.

Also, is there an issue for this error message?

James McKenzie

[James McKenzie]

Timeout wrote:

fixme:virtual:NtAllocateVirtualMemory MEM_WRITE_WATCH type not supported

is probably NOT the reason for the crash.

I have it too on my .NET application and I can safely ignore it because the application is not affected.

If you read some documentation about the net, you will see that the .NET is using JIT and not MEM_WRITE_WATCH but MEM_WRITE_WATCH is used by Visual Basic which leads me to the (uneducated) opinion that this error is just thrown by the C++ on which the .NET is based.
However as per WINDOWS_2000 if MEM_WRITE_WATCH is not supported, it is just ignored by the concerned components.

I will not fire you for this, but some programs are written with VB.NET
and thus may be affected by this problem. I could name one here, but
I'm under a Non-Disclosure Agreement with its manufacturer.'

James Mckenzie

[Timeout]

Maybe you are right. I just found this information on an interview about the release of the .NET when I was looking for this error myself.
I would not even recognize a VB .NET application even if it were in front of my nose.

quote:

It seems that there is. The Windows VirtualAlloc function allows us to specify that the allocated region should be "write watched" (using the MEM_WRITE_WATCH flag) so that further writes to it will be recorded and can then be retrieved using the GetWriteWatch API. The granularity of the watch, naturally, is in pages, so it requires more work on the garbage collector's side after determining that the area has been written to, but it seems that the performance gains (from not using the JIT-generated write barrier thunk) should be more significant.

The question I was talking about, then, is why doesn't the .NET GC use this built-in memory watch mechanism, supplied by the Win32 API? The following blog entry notes this possibility (in section 3.2.4), but does not elaborate regarding the reasons behind the particular choice made in .NET. I have several speculations (which are just that - speculations) and am still pursuing a more definitive answer:

* The aforementioned API is not supported on Windows 95 (which is, perhaps, not so surprising), but it is not supported on Windows 2000 as well. This would limit the .NET framework's compatibility with these platforms (although in those particular cases the JIT-thunk approach could be adopted).
* The aforementioned API is Windows-specific and does not provide any compatibility with other platforms. The JIT-generated write barrier is generic and theoretically can work on any platform.
* The performance penalty of using the MEM_WRITE_WATCH flag for writing to a region of memory is bigger than the thunk generated by the JIT. Note that a very primitive measurement I've performed indicates an 8% performance penalty when writing to memory protected by a write watch as opposed to writing to memory that is not protected by a write watch (don't quote me on this ).
End of quote
http://blogs.microsoft.co.il/blogs/sash ... riers.aspx

[MasterTH]

i dont know if there's an issue??

[Timeout]

I can't tell you in your case. maybe you should look with +relay. Last year when I was blocked by the .NET with this fixme as (nearly last) error message, it was kernel32 which was blocked due to a memory leak (waiting for something to return a call, which never came).

[MasterTH]

what do you mean with "+relay"??? Start the program with this option?

[Timeout]

I mean instead of running "wine yourapp.exe" you run "WINEDEBUG=+relay wine yourapp.exe" (without quotes of course.

You will see that there are pairs of calls and answers.
look at the last lines if every call has an answer (usually the answer has a part of the number of the call within it). If not, that's your problem and not MEM_TYPE_WATCH.

Look at the last lines. If there is something abnormal in the last lines, maybe one of the developer will ask you for more information but to see if not the last call is hanging, the last 10 lines are enough.

[MasterTH]

sorry but there's nothing different in the console output with this command.

this is everything i'v got

Code: Select all

linux-c5xy:~ # wine .wine/drive_c/Program\ Files/SD.NET/bin/SD.NETstart2.exe
fixme:virtual:NtAllocateVirtualMemory MEM_WRITE_WATCH type not supported
fixme:virtual:NtAllocateVirtualMemory MEM_WRITE_WATCH type not supported
fixme:shell:URL_ParseUrl failed to parse L"mscorlib"
fixme:shell:URL_ParseUrl failed to parse L"System.Data"
fixme:event:wait_for_withdrawn_state window 0x10026/1200005 wait timed out

Unhandled Exception: StackOverflowException.
wine: Unhandled exception 0xe0434f4d at address 0x7b844f10 (thread 0009), starting debugger...
Unhandled exception: 0xe0434f4d in 32-bit code (0x7b844f92).
Register dump:
 CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b
 EIP:7b844f92 ESP:0033f3e0 EBP:0033f444 EFLAGS:00000246(   - 00      - IZP1)
 EAX:7b82ec69 EBX:7b8b2ff4 ECX:00137840 EDX:00000000
 ESI:00137840 EDI:00000000
Stack dump:
0x0033f3e0:  0014bd70 000001d2 00149940 1100355c
0x0033f3f0:  e0434f4d 00000001 00000000 7b844f10
0x0033f400:  00000000 0033f418 791b9d02 008a1180
0x0033f410:  048c2568 00137840 0033f430 791be271
0x0033f420:  00134160 00000002 048c2568 00000000
0x0033f430:  0033f440 791be286 00134160 048c2568
Backtrace:
=>1 0x7b844f92 RaiseException+0x82() in kernel32 (0x0033f444)
  2 0x7921020d in mscorwks (+0x6020d) (0x0033f49c)
  3 0x79210190 in mscorwks (+0x60190) (0x0033f4c4)
  4 0x79210144 in mscorwks (+0x60144) (0x0033f4d4)
  5 0x79256dcb in mscorwks (+0xa6dcb) (0x0033f5ac)
  6 0x791d6a7e in mscorwks (+0x26a7e) (0x0033f5c4)
  7 0x00137eae (0x0033f5f8)
  8 0x791da434 in mscorwks (+0x2a434) (0x0033f708)
  9 0x791da58a in mscorwks (+0x2a58a) (0x0033f7b8)
  10 0x791da5f6 in mscorwks (+0x2a5f6) (0x0033f7e0)
  11 0x7921f818 in mscorwks (+0x6f818) (0x0033f898)
  12 0x7923d342 in mscorwks (+0x8d342) (0x0033f9ac)
  13 0x7923d441 in mscorwks (+0x8d441) (0x0033f9c4)
  14 0x7923d92f in mscorwks (+0x8d92f) (0x0033fca8)
  15 0x791c6e73 in mscorwks (+0x16e73) (0x0033fee8)
  16 0x791c6ef3 in mscorwks (+0x16ef3) (0x0033ff08)
  17 0x7b8752ae start_process+0xee() in kernel32 (0x0033ffe8)
  18 0xb7e03a77 wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000)
0x7b844f92 RaiseException+0x82 in kernel32: movl        0xfffffffc(%ebp),%ebx
Modules:
Module  Address                 Debug info      Name (69 modules)
PE        670000-  6b5000       Deferred        fusion
PE      11000000-1100e000       Deferred        sd.netstart2
PE      51a70000-51af0000       Deferred        diasymreader
PE      79000000-79045000       Deferred        mscoree
PE      791b0000-79412000       Export          mscorwks
PE      79430000-7947c000       Deferred        mscorjit
PE      79510000-79523000       Deferred        mscorsn
PE      796e0000-7971e000       Deferred        shfusion
PE      79980000-79ca6000       Deferred        mscorlib
ELF     7b800000-7b92c000       Export          kernel32<elf>
  \-PE  7b820000-7b92c000       \               kernel32
ELF     7bc00000-7bca5000       Deferred        ntdll<elf>
  \-PE  7bc10000-7bca5000       \               ntdll
ELF     7bf00000-7bf04000       Deferred        <wine-loader>
PE      7c340000-7c396000       Deferred        msvcr71
ELF     7e235000-7e253000       Deferred        imm32<elf>
  \-PE  7e240000-7e253000       \               imm32
ELF     7e280000-7e29a000       Deferred        version<elf>
  \-PE  7e290000-7e29a000       \               version
ELF     7e29a000-7e33d000       Deferred        oleaut32<elf>
  \-PE  7e2b0000-7e33d000       \               oleaut32
ELF     7e584000-7e597000       Deferred        libresolv.so.2
ELF     7e59b000-7e5b0000       Deferred        lz32<elf>
  \-PE  7e5a0000-7e5b0000       \               lz32
ELF     7e5b0000-7e5cf000       Deferred        iphlpapi<elf>
  \-PE  7e5c0000-7e5cf000       \               iphlpapi
ELF     7e5cf000-7e62f000       Deferred        rpcrt4<elf>
  \-PE  7e5e0000-7e62f000       \               rpcrt4
ELF     7e62f000-7e6d4000       Deferred        ole32<elf>
  \-PE  7e640000-7e6d4000       \               ole32
ELF     7e6e6000-7e719000       Deferred        uxtheme<elf>
  \-PE  7e6f0000-7e719000       \               uxtheme
ELF     7e719000-7e7d9000       Deferred        comctl32<elf>
  \-PE  7e720000-7e7d9000       \               comctl32
ELF     7e7d9000-7e8e1000       Deferred        shell32<elf>
  \-PE  7e7f0000-7e8e1000       \               shell32
ELF     7e8e1000-7e8e7000       Deferred        libxfixes.so.3
ELF     7e8e7000-7e8f1000       Deferred        libxcursor.so.1
ELF     7e8f1000-7e8f8000       Deferred        libxrandr.so.2
ELF     7e8f8000-7e901000       Deferred        libxrender.so.1
ELF     7e936000-7e94f000       Deferred        libxcb.so.1
ELF     7e94f000-7ea6a000       Deferred        libx11.so.6
ELF     7ea6a000-7ea79000       Deferred        libxext.so.6
ELF     7ea79000-7ea92000       Deferred        libice.so.6
ELF     7eaab000-7eb3d000       Deferred        winex11<elf>
  \-PE  7eac0000-7eb3d000       \               winex11
ELF     7ebf1000-7ec12000       Deferred        libexpat.so.1
ELF     7ec12000-7ec3e000       Deferred        libfontconfig.so.1
ELF     7ec3f000-7ec43000       Deferred        libxinerama.so.1
ELF     7ec57000-7ecc6000       Deferred        libfreetype.so.6
ELF     7ecc6000-7ed60000       Deferred        gdi32<elf>
  \-PE  7ece0000-7ed60000       \               gdi32
ELF     7ed60000-7eea0000       Deferred        user32<elf>
  \-PE  7ed80000-7eea0000       \               user32
ELF     7eea0000-7eefa000       Deferred        shlwapi<elf>
  \-PE  7eeb0000-7eefa000       \               shlwapi
ELF     7eefa000-7ef47000       Deferred        advapi32<elf>
  \-PE  7ef10000-7ef47000       \               advapi32
ELF     7efc2000-7efe7000       Deferred        libm.so.6
ELF     7efe7000-7efed000       Deferred        libxxf86vm.so.1
ELF     7efed000-7f000000       Deferred        libz.so.1
ELF     b7c91000-b7c94000       Deferred        libxcb-xlib.so.0
ELF     b7c95000-b7c99000       Deferred        libdl.so.2
ELF     b7c99000-b7dcc000       Deferred        libc.so.6
ELF     b7dcc000-b7de3000       Deferred        libpthread.so.0
ELF     b7de4000-b7de8000       Deferred        libxau.so.6
ELF     b7de8000-b7df1000       Deferred        libsm.so.6
ELF     b7dfc000-b7f11000       Export          libwine.so.1
ELF     b7f12000-b7f2e000       Deferred        ld-linux.so.2
Threads:
process  tid      prio (all id:s are in hex)
00000008 (D) Y:\.wine\drive_c\Program Files\SD.NET\bin\SD.NETstart2.exe
        00000014    2
        00000013    0
        00000009    0 <==
0000000a
        0000000b    0
0000000c
        0000000e    0
        0000000d    0
0000000f
        00000012    0
        00000011    0
        00000010    0
00000015
        00000017    0
        00000016    0
Backtrace:
=>1 0x7b844f92 RaiseException+0x82() in kernel32 (0x0033f444)
  2 0x7921020d in mscorwks (+0x6020d) (0x0033f49c)
  3 0x79210190 in mscorwks (+0x60190) (0x0033f4c4)
  4 0x79210144 in mscorwks (+0x60144) (0x0033f4d4)
  5 0x79256dcb in mscorwks (+0xa6dcb) (0x0033f5ac)
  6 0x791d6a7e in mscorwks (+0x26a7e) (0x0033f5c4)
  7 0x00137eae (0x0033f5f8)
  8 0x791da434 in mscorwks (+0x2a434) (0x0033f708)
  9 0x791da58a in mscorwks (+0x2a58a) (0x0033f7b8)
  10 0x791da5f6 in mscorwks (+0x2a5f6) (0x0033f7e0)
  11 0x7921f818 in mscorwks (+0x6f818) (0x0033f898)
  12 0x7923d342 in mscorwks (+0x8d342) (0x0033f9ac)
  13 0x7923d441 in mscorwks (+0x8d441) (0x0033f9c4)
  14 0x7923d92f in mscorwks (+0x8d92f) (0x0033fca8)
  15 0x791c6e73 in mscorwks (+0x16e73) (0x0033fee8)
  16 0x791c6ef3 in mscorwks (+0x16ef3) (0x0033ff08)
  17 0x7b8752ae start_process+0xee() in kernel32 (0x0033ffe8)
  18 0xb7e03a77 wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000)

[Timeout]

In this case the problem is a stack overflow and not MEM_WRITE_WATCH.
For this you should file a bug (if not filed yet for your application) giving all details possible to repeat the bug.

[Timeout]

About the stack overflow:

It looks like you used "su" before launching the setup.
What's happens if you type "exit" and you start again. Do you have the same?