ProjectWise Explorer White-Screen Socket Close Failure [TN]

 Applies To 
 Version(s):08.09.03.xx through and 08.09.04.xx through
 Environment: N/A
 Area: N/A
 Subarea: N/A
 Original Author:Bentley Technical Support Group










Problem Description 

When this issue occurs, a user will see a white-screen instead of the ProjectWise Explorer interface. The white screen will continue to display for as long as PWE remains connected. This is commonly experienced when PWE is minimized on the task bar for more than 10 minutes and then a command needed to access ProjectWise is started. Exiting and starting a new session of PWE restores the connection and the command is quickly carried out.

NOTE: This should NOT be confused with an operational white-screen. An operational white-screen will display for 2 or 3 minutes during a long ProjectWise transaction because a task is being completed. Exiting and restarting PWE will NOT resolve this issue because there is nothing wrong.


The ProjectWise Server was modified to use an alternate command to close the socket on the PWE Client. This is a higher-priority socket close command and thus gets delivered more reliably to the Client. 
• For 08.09.03.xx through, this is available in 
• For 08.09.04.xx through, this is available in or higher
NOTE:This only requires a Server upgrade.

Diagnosing the Problem:

If you have seen this scenario and need additional clarification before upgrading, TSG can assist in the analysis. 
To determine if your ProjectWise implementation is encountering this issue TSG will need to gather network logging. To get accurate logging we will ask you about your TCP Chimney settings.

Step 1: TCP Chimney

Check to see if the TCP Chimney is disabled, as a Microsoft service pack automatically enables TCP Chimney. Microsoft has published articles noting that this setting can affect network connection and speed. To determine if TCP chimney is enabled on a server look for the following registry key: reg export HKLM\SYSTEM\CurrentControlSet\Services\Tcpip REG_TCPIP_(%COMPUTERNAME%).reg.txt

It is our experience that as part of the troubleshooting process for network application connectivity issues, the TCP chimney feature needs to be disabled on any servers that are used to support the network application. For additional information about the TCP Chimney see Jo West's Blog onDisabling the TCP Chimney

To disable the TCP chimney, key-in this command from a command window on the server: netsh int ip set chimney DISABLED

Step 2: Network Traffic capture

• Install Wireshark on the computer with ProjectWise Explorer.
• Reproduce the white-screen in order to capture the Network traffic
• Send Wireshark logging to TSG.

Step 3: PWC and DMSKRNL logging

• Set the PWC.log and DMSKRNL.log files to ALL
• Reproduce the white screen to capture the logging. **The logging need to be done at the same time as the Wireshark capture.
• Send both logs to TSG

The Wireshark data, PWC, and DMSKRNL.log files will be used to identify the signature of the problem. If help is needed on completing these steps, contact TSG.

Detailed Overview:

If ProjectWise Explorer is not actively communicating with the Integration Server for 10 minutes or more, the socket is closed by the Server (meaning the client/server connection is terminated). When the user invokes a ProjectWise Explorer command, whether from an integrated application or from ProjectWise Explorer itself, the Client requests a new connection and the Server responds. 
The white screen results because the PW Integration Server sends out the message to close the socket. Therefore, the Server is not monitoring that socket. The Client does not receive the command that the socket is closed. The Client then sends the next request for the Server on the closed socket and waits for a Server response.

NOTE: We believe this communication lapse is due to the operating system being too busy to deliver the close command.

The Server doesn't receive the request from the Client because it not monitoring the closed socket. While the Client waits for a response the Client is in a busy state and doesn't repaint the GUI. The result is the "White Screen" or "Frozen" application, The Task Manager will report this state as non-responsive. This isn't really true the application is busy and will respond as soon as it isn't busy. Sometimes the Client will get the socket close command from the OS while waiting and reconnect to the server. This ends the white screen event and returns the Client to a normal state. If the close command has not been received any action on the Client which disrupts the connection will return the client to a normal state.

In addition to changing the socket close command, we have added a Client failsafe that will close the socket even if the Server request hasn't received. You might think of this as the "You can't fire me I quit" command for the Client connection. This setting can be controlled by a configuration variable.

This design enables the Server to handle a larger number of users than it could if all users stayed connected at all times. It also conserves bandwidth and improves the overall performance of the network. This design is a common "Best Practice" Design for Client / Server applications.

Microsoft offers a variety of commands to support the Client/Server architecture as described above. One of those commands (the one we used) will send out a socket disconnect that essentially tells the network to disconnect socket XYZ when it isn't busy. The Client receives the notification to close the socket and it no longer has an active session with the Server.

The next time the user of the Client computer needs information from the Server, if the socket has been closed, ProjectWise Explorer asks the Integration Server for a new connection. The Client receives the connection response and returns the requested information. This request and the resulting connection are very fast. If the connection hasn't closed, ProjectWise Explorer sends the request for information to the Integration server without asking for a new connection. Any time difference in these transactions is negligible.

Comments or Corrections?

Bentley's Technical Support Group requests that you please confine any comments you have on this Wiki entry to this "Comments or Corrections?" section. THANK YOU!