Custom Query (6 matches)

XWorkplace crashed during shutdown. I attempted to comply with Please send a bug report to xworkplace-user@…, but your e-mail server rejected it with the message <xworkplace-user@…>: ezmlm-issubn: fatal: unable to open allow/subscribers/T: access denied Sorry, only subscribers may post.

I am attaching the trap log for the original problem, and suggest that the text in xwptrap be amended to either provide a deliverable address or to describe the need to subscribe.

In \src\startshut\apm.c function VOID acpiDoPowerOff(VOID) line 406 DosSleep?(700); has to be used to switch down my system reliable.

I tested this over many years and retested again the latest months. My MSI board needs 700ms instead the 250ms which is in the official sources. Shutdown on this system does not work reliable with values <700ms. Most of the time shutdown works with 250ms and 500ms too. But reliable switching off monitor out and all fans is only guaranteed with 700ms. Here is the relevant part of the code with my comments over the years. As you can see I watch this problem since many years. No clue how many systems out there are do not fully shut down sporadically as mine. But I'm pretty sure my system is not the only one. But probably I'm the only one who observed this problem and tested with different values long enough to assure this is the place where the problem can be fixed.

VOID acpiDoPowerOff(VOID)
{
     ULONG i, ulCpuCount = 1;

     /* Set all CPUs to OffLine, except CPU 1 */
     DosQuerySysInfo(QSV_NUMPROCESSORS, QSV_NUMPROCESSORS, &ulCpuCount, sizeof(ulCpuCount));
     for (i = 2; i <= ulCpuCount; i++)
         DosSetProcessorStatus(i, PROC_OFFLINE);

    DosSleep(700);  // @@changed V1.0.9 (2009-05-29) [shl]: ensure system really has time to go idle
                    // @@changed V1.0.10(2014-04-29) [AB]: test with 500 instead 250
		// @@changed V1.0.10(2014-04-29) [AB]: test with 700 cause sometimes video out (X300) is not switched off
		// @@changed V1.0.13(2020-01-16) [AB]: test with 250 again cause this is in official version from Rich
		// @@changed V1.0.13(2020-02-16) [AB]: back to 500 as 250 definitely does not reliable switch of video out AND fans
		// @@changed V1.0.13(2020-03-01) [AB]: back to 700 as 500 is definitely not reliable too
    acpihGoToSleep(&G_hACPI, ACPI_STATE_S5);
    acpihClose(&G_hACPI);
}

using XWP 1.0.13:

there are three named event semaphores that are using by the "WinWaitForShell?" API function so that this function can block on (or being polled for) these 3 events: Desktop created, Desktop opened, Desktop populated.

The named event semaphores are: \SEM32\WORKPLAC\SHELL1WT.SEM (for Desktop created) \SEM32\WORKPLAC\SHELL2WT.SEM (for Desktop opened) \SEM32\WORKPLAC\SHELL3WT.SEM (for Desktop populated)

These 3 event semaphores are created by the 1. instance of PMSHELL.EXE but they are opened and set by the 2. instance of PMSHELL.EXE.

The problem is, that on XWP function "WPS restart", the 2. instance is just terminating thread 1 (which leads to process termination) without resetting these event semaphores. If the WPS is then restarted and an application also starting up (or the WPS) is using "WinWaitForShell?" waiting for the desktop to be created/opened/populated respectively, the "WinWaitForShell?" API call will return immediately without blocking because the event semaphores are still set. This typically leads to hang problems and the like because the WPS is typically not in the state that the application/WPS class expects it to be after returning from "WinWaitForShell?". One indication of such might be WPS classes installed via WarpIn? and requiring a WPS restart to become active where the WPS restart will lead to a system hang.

I propose to reset these 3 event semaphores shortly before the 2. instance of PMSHELL.EXE terminates its thread 1 (on a "WPS restart").