Windows service/console program does not exit on page fault

Questions about Wine on Linux
Locked
rms-mit
Newbie
Newbie
Posts: 4
Joined: Mon Nov 25, 2019 5:03 pm

Windows service/console program does not exit on page fault

Post by rms-mit »

Hi

I have never never asked a question on Wine Forums and have only used wine a few times although I have played with it from time to time over the years.

I am trying to run a windows service in a wine text only console. This is in a docker container and is working fine but occasionally has a page fault
wine: Unhandled page fault on read access to 0x00000000 at address 0x1000697a (thread 00e4), starting debugger

This is not a problem in itself as it occurs only once in a while. The issue is that if it page faults, it does not exit so that it can be detected and restarted but instead spits out the error and tries to launch Debugger window, which offcourse fails since it is text only. At this point it just hangs and never actually exits. This means it is never auto-restarted.

The Question is . . . . Is there a way to turn of this debugging feature so that when this page fault occurs the wine program just exits. It would be nice to dump debug data before exiting but it NEEDS to exit or the service will never recover.

Please help

Thank you
rms-mit
Newbie
Newbie
Posts: 4
Joined: Mon Nov 25, 2019 5:03 pm

Re: Windows service/console program does not exit on page fault

Post by rms-mit »

Thank you for that link.

It did take me a while to get it to work because the FAQ page says you just need a plain file but I found that the file needed the text "REGEDIT4" at the top before the actual registry entry you wanted to enter or it would fail silently.

FAQ says file should be just

Code: Select all

[HKEY_CURRENT_USER\Software\Wine\WineDbg]
"ShowCrashDialog"=dword:00000000
But I needed :-

Code: Select all

REGEDIT4

[HKEY_CURRENT_USER\Software\Wine\WineDbg]
"ShowCrashDialog"=dword:00000000
I had also ensured that the file was dos format (ie CR/LF line terminators) I am unsure if this also had something to do with the registry entry not being applied but I used "todos" command to convert to dos format for me. Now when I do

regedit /E - 'HKEY_CURRENT_USER\Software\Wine'|tail

I see the entry.
rms-mit
Newbie
Newbie
Posts: 4
Joined: Mon Nov 25, 2019 5:03 pm

Re: Windows service/console program does not exit on page fault

Post by rms-mit »

Further development.

The reg entry is in but Wine still tried to load Debugger window and did not exit the program when the page faulty occurred.

In summary I am passing the environmental variable and proved it was in the processes environment.

Code: Select all

WINEDEBUG=-all
and I have set the registry entry in the docker container environment using

Code: Select all

#regedit ./crashdialog.reg
#regedit /E - 'HKEY_CURRENT_USER\Software\Wine'|tail
.
.
[HKEY_CURRENT_USER\Software\Wine\WineDbg]
"ShowCrashDialog"=dword:00000000
What I am getting from the docker logs is

Code: Select all

2019-11-28T03:06:33.972614142Z wine: Unhandled page fault on read access to 0x00000000 at address 0x1000697a (thread 0046), starting debugger...
2019-11-28T03:06:33.982620970Z Can't attach process 0008: error 5
2019-11-28T03:06:33.994706447Z 0049:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
2019-11-28T03:06:33.994720178Z 0049:err:winediag:nodrv_CreateWindow Make sure that your X server is running and that $DISPLAY is set correctly.
We do intend to fix the page fault but I also need it to exit so the sort autorestart will take effect and reduce the impact of the crash.

Thank you
rms-mit
Newbie
Newbie
Posts: 4
Joined: Mon Nov 25, 2019 5:03 pm

Re: Windows service/console program does not exit on page fault

Post by rms-mit »

I have not had further occurrences of this issue. I did not change anything further so I suspect that one of the above changes did work but I had not taken effect till after a further restart of the container. I will be adding these config changes to the build process and testing the fresh build in the lab to prove all is OK. Then I will see about deployment to field and see if the issue ever comes back.
Locked