https://bugs.winehq.org/show_bug.cgi?id=47894
Bug ID: 47894 Summary: mfreadwrite error dialog causes the user32:winstation tests to fail Product: Wine Version: 4.17 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mfplat Assignee: wine-bugs@winehq.org Reporter: sven.wine@gmail.com Distribution: ---
When mfreadwrite is not present, a dialog appears, which seems to cause the user32:winstation tests to fail:
https://test.winehq.org/data/b360cd67e8f7f8c01f09457bacb032fd4a248d0a/2008_n...
Sometimes it disappears just in time, in which case the tests succeed:
https://test.winehq.org/data/b360cd67e8f7f8c01f09457bacb032fd4a248d0a/2008_n...
I'm not sure whether to file this under user32 or mfreadwrite.
https://bugs.winehq.org/show_bug.cgi?id=47894
--- Comment #1 from Nikolay Sivov bunglehead@gmail.com --- Does it complain about specific function missing in mfreadwrite? I thought automatically running tests detected missing libraries and skipped everything. Or is it specific to Windows Server?
https://bugs.winehq.org/show_bug.cgi?id=47894
--- Comment #2 from Sven sven.wine@gmail.com --- I'm not sure about the actual error dialog, since I don't have a Windows installation to test it on, but you can find an error dialog in the logs with the title "mfreadwrite_test.exe - Unable To Locate Component". In the logs on Windows XP, there is a similar dialog for mfplat, but that one doesn't seem to cause the failure (even tough there are other failures):
https://test.winehq.org/data/7d954f23356f0aaf49b1ef0c4bed83041cb41c08/xp_fg-...
I'm not sure how winetest is supposed to handle missing libraries, but I found it weird that the test only fails if the error dialog is present.
It could also be that the winstation tests should just be fixed, since the test also fails sporadically on Windows 7, but without the mfreadwrite error dialog being present:
https://test.winehq.org/data/363b8809f37b3ea5915ea4240b3d397fd2355e2e/win7_f...
https://bugs.winehq.org/show_bug.cgi?id=47894
Sven sven.wine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|mfplat |user32 Keywords| |download, source, testcase Summary|mfreadwrite error dialog |Error dialogs cause the |causes the |user32:winstation tests to |user32:winstation tests to |fail |fail |
--- Comment #3 from Sven sven.wine@gmail.com --- They also fail because of other error dialogs, so removing the mfplat component
https://test.winehq.org/data/190fb605c34ac1365076dff0a6560ddb42ca1ef2/win7_n... https://test.winehq.org/data/190fb605c34ac1365076dff0a6560ddb42ca1ef2/win10_...
I tried to write a testcase for this, but I haven not yet succeeded in creating a window that persists in the foreground after calling SetForegroundWindow on another window.
https://bugs.winehq.org/show_bug.cgi?id=47894
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fgouget@codeweavers.com, | |z.figura12@gmail.com
--- Comment #4 from Zebediah Figura z.figura12@gmail.com --- I think most of these are caused by missing dependencies even where the main dll is present. One solution to this is to do as TestLauncher does and refuse to run tests when any imported DLLs are missing. On the other hand, I suspect that at least some of these missing dependencies are unintentional. For example, the wxppro machines apparently have mfplat but not d3d11 (or, weirdly, any other MF DLLs); we can just as easily load the latter at runtime.
A weird case is François' fg-winxp-lusr machine, which has windowscodecs but not propsys. MSDN implies that propsys should be present since at least SP2, though, and it's clearly present on the TestBot XP machine. François, do you have any idea why propsys is missing on that machine?
https://bugs.winehq.org/show_bug.cgi?id=47894
--- Comment #5 from Zebediah Figura z.figura12@gmail.com --- Others:
* 2008 apparently has mfreadwrite, but not mfplat, which is head-scratchingly bizarre. In fact, even after removing all references to mfplat from the test it still fails, probably because mfreadwrite links to mfplat. What the hell, Microsoft?
* w7pro64 seems to have d3dcompiler_47 but not d3dx9_36 (or d3dcompiler_43). There are some tests that we can do without d3dx9_36, so I guess we should probably link that dynamically. Or maybe just install d3dx9 on that machine?
* Intermittent and inexplicable failures to load various tests on various machines. I don't see any sign of these in screenshots, however... - http://test.winehq.org/data/6e4d441ce11739b145dae200d7b20743c64147de/win7_newtb-w7pro64-32/version.html - failure to load comdlg32. - http://test.winehq.org/data/5034d109e033fbe820829ae43adba0cc30bf9b99/win7_newtb-w7pro64-32/version.html - failure to load amstream. - http://test.winehq.org/data/fa97cbdf14883fb301dcc0a5264369f8ed184182/win7_newtb-w7pro64-32/version.html - failure to load avifil32 and comdlg32. - http://test.winehq.org/data/6e4d441ce11739b145dae200d7b20743c64147de/win10_newtb-w1064v1809-zh-CN-32/version.html - advpack, uiautomationcore, user32, webservices, winmm, wmvcore.
* Windows 10 (and possibly others) trigger on a different kind of dialog, which also seems to be causing comctl32 failures. Something in comctl32 is leaking memory, apparently? See the following dialogs: - https://testbot.winehq.org/JobDetails.pl?Key=62492&s108=1#k108: "Le processus est terminé, car il est impossible d'allouer davantage de mémoire." Apparently from comctl32:button. - https://testbot.winehq.org/JobDetails.pl?Key=62325&s110=1#k110: "O aplicativo não pôde ser inicializado corretamente (0xc000012d). Clique em OK para fechar o aplicativo." That's STATUS_COMMITMENT_LIMIT, apparently from comctl32:imagelist. - http://test.winehq.org/data/5034d109e033fbe820829ae43adba0cc30bf9b99/win10_newtb-w1064v1809-ru-32/report.html — the corresponding screenshot only shows an empty dialog box, but comctl32:taskdialog hangs. - https://testbot.winehq.org/JobDetails.pl?Key=61734&s109=1#k109: "The application was unable to start correctly (0xc0000142). Click OK to close the application." That's STATUS_DLL_INIT_FAILED, apparently from comctl32:pager.
https://bugs.winehq.org/show_bug.cgi?id=47894
--- Comment #6 from François Gouget fgouget@codeweavers.com --- (In reply to Zebediah Figura from comment #4)
A weird case is François' fg-winxp-lusr machine, which has windowscodecs but not propsys. MSDN implies that propsys should be present since at least SP2, though, and it's clearly present on the TestBot XP machine. François, do you have any idea why propsys is missing on that machine?
I don't know why propsys.dll is missing. windowscodecs.dll appeared in the SP3 snapshot but propsys.dll is missing from all snapshots, back to the original one.
https://bugs.winehq.org/show_bug.cgi?id=47894
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |5da10c9a0e405c4b502be820ae0 | |385d634306a76 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Severity|normal |major
--- Comment #7 from François Gouget fgouget@codeweavers.com --- The initial report does not mention the actual test failure. So here it is for reference (unless I'm mistaken):
winstation.c:973: Test failed: unexpected foreground window 00070064
These days it impacts a relatively wide range of Windows configurations regardless of bitness: w2008s64, win7u64-1spie9 (French and Spanish), w1064v1809 (French, Hebrew, Japanese, Portuguese, Russian).
See: https://test.winehq.org/data/tests/user32:winstation.html
Furthermore the window handle changes with every run which means this failure is "always new". Because of this the TestBot will report most user32 patches as responsible for this failure which should cause them to be rejected. Thus fixing this issue is high priority.
Note that a workaround for the "always new" aspect would be to not include the window handle in the failure message. Including the window title instead may actually make more sense and would avoid most of the false positives.
The commit that introduced this test is:
commit 5da10c9a0e405c4b502be820ae0385d634306a76 Author: Qian Hong qhong@codeweavers.com AuthorDate: Tue Oct 8 11:40:26 2013 +0800
user32/tests: Added foreground window tests on different desktops.
Looking at the reports on test.winehq.org there are two main types of windows that cause this failure:
* "Unable To Locate Component" dialogs (all w2008s64 failures) As mentioned in the previous comments: mfreadwrite_test.exe - Unable To Locate Component
These are triggered by WineTest itself when it tries to get the list of test units. See the "load error 1359" bug 48062. But I would argue these are far from the majority of the troublesome windows. Interestingly there are a couple of cases where user32:winstation did not fail on w2008s64 despite the presence of the "mfreadwrite=load error 1359" error. Does this window go away sometimes?
* "FileSyncConfig.exe - AvP[V G[" (1x w1064) This is a OneDrive dialog on Windows 10 :-((( WTH!!!
* "Program Manager" window (1x win7u64-1spie9-fr) Program Manager
* "" untitled window (1x win7u64-1spie9-es) No idea what this is.
* "Application Error" dialogs (11x w1064) amstream_test.exe - Application Error crypt32_test.exe - Application Error d3dcompiler_43_test.exe - Îøèáêà ïðèëîæåíèÿ ddraw_test.exe - Erro de aplicativo dwrite_test.exe - Erreur d'application ieframe_test.exe - Erreur d'application inetcomm_test.exe - Erreur d'application kernel32_test.exe - Erreur d'application
These all correspond to timed out tests. Yet, as far as I can tell WineTest kills tests that time out. So this means that either TerminateProcess() failed or that the window did not belong to the process (DrWatson?).
It may be possible to modify WineTest to get rid of the two main sources of these windows; and it should be possible to reconfigure OneDrive so it does not pop up dialogs.
However I would argue that winstation should just be more robust. Except for the three outliers (Program Manager, OneDrive and untitled window), I suspect that the window was present long before user32:winstation started. That should make it easy to detect it (or them?) and take it into account so the test does not fail; or even to skip that part of the test.
https://bugs.winehq.org/show_bug.cgi?id=47894
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
https://bugs.winehq.org/show_bug.cgi?id=47894
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WORKSFORME
--- Comment #8 from Zeb Figura z.figura12@gmail.com --- I don't know how this was addressed (by disappearing the affected machines?), but it doesn't occur anymore. I'm not sure I can confidently say this was fixed or abandoned, so I'm going with WORKSFORME.
https://bugs.winehq.org/show_bug.cgi?id=47894
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #9 from Austin English austinenglish@gmail.com --- Closing.
-
WineHQ Bugzilla