[Bug 47894] New: mfreadwrite error dialog causes the user32:winstation tests to fail
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(a)winehq.org Reporter: sven.wine(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=47894 --- Comment #1 from Nikolay Sivov <bunglehead(a)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? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=47894 --- Comment #2 from Sven <sven.wine(a)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... -- 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.
https://bugs.winehq.org/show_bug.cgi?id=47894 Sven <sven.wine(a)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(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=47894 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fgouget(a)codeweavers.com, | |z.figura12(a)gmail.com --- Comment #4 from Zebediah Figura <z.figura12(a)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? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=47894 --- Comment #5 from Zebediah Figura <z.figura12(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=47894 --- Comment #6 from François Gouget <fgouget(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=47894 François Gouget <fgouget(a)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(a)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(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=47894 Gijs Vermeulen <gijsvrm(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression -- 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.
https://bugs.winehq.org/show_bug.cgi?id=47894 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #8 from Zeb Figura <z.figura12(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=47894 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #9 from Austin English <austinenglish(a)gmail.com> --- Closing. -- 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.
participants (1)
-
WineHQ Bugzilla