Vault Pro 9.1 Hang on Startup After Selecting Repo

[Matthew]

We just upgraded from Vault 6 Pro to Vault 9.1 Pro.
Several of us have noticed that at times when we log into the Vault Professional Client it hangs with the spinning disk. (Running on Win 7) This happens after:

1. Launch the Vault Pro Client
2. Log in
3. Select the repository
4. Watch spinning disk for as long as desired

Most of the menu options are disabled. Abort is enabled but clicking it does nothing. It never resolves by itself. The solution is to click the X to close the program and try again. Sometimes several times. But eventually it goes right in.
We never had this problem using Vault 6.
This is happening to more than 1 user.
Once we get past the initial startup issue the client seems to work fine.
I tried turning off "Check for latest Vault version at startup" but this didn't change the problem.
I tried turning off "Use Expect: 100-Continue headers (for low latency networks)" but I still experience the problem.
Once connected successfully, I tried selecting File->Disconnect from server and then File-Connect to server to see if I could get it to fail but I could not replicate the failure this way. To replicate the failure I have to close out of the program and open it again. Granted, I only tried this half a dozen times but when opening the program it seems to fail about 50% of the time.
Thanks in advance for your help!

[Beth]

Try out the suggestions in this KB article: viewtopic.php?f=13&t=22633.

[Matthew]

Thanks for the suggestions. I went through the list and tried everything I could but I am still seeing the problem.
I did notice on the step 5 that the query SELECT COUNT(*) FROM sgnotify.dbo.events; is still showing 7 even though I cleared out event details and restarted the Vault Notification App Pool. (SELECT COUNT(*) FROM sgnotify.dbo.eventdetails; shows 0)
Just to reiterate, we did not see this problem on Vault 6 with the same server and same SQL server and database.
Thanks!

[jclausius]

Matthew,

Do you have the auto-login / auto-choose repository option enabled? If not, you could try this:

1) Start up the Vault GUI Client.
2) Log in to the server, but DO NOT choose a repository. Hit Cancel on that dialog.
3) Next go to Tools -> Options -> Network Settings. UNCHECK the 'Request database delta on repository cache miss'.
4) Click OK on the options.

Now try to log in and choose a repository.

[Matthew]

Hi Jeff,
No, I don't have auto-login/auto-choose enabled. Do you think that would help or hurt?
It does work about 50% of the time so after closing out and trying again a time or two I can get in. Once I am in it works fine.
I had already unchecked the "Request database delta..." option as step 1 of the troubleshooting steps in the prior link.
Thanks,

[jclausius]

It could be something related to the cache. This isn't on a VM or something where it rolls back on shutdown is it?

There are some other configuration settings you could also check. Have you already checked out these suggestions with your configuration - viewtopic.php?f=13&t=22633

[Matthew]

Jeff,
The clients are desktop PCs and not VMs. The server is likely a VM but an enterprise grade VM that doesn't get shut down. (It gets rebooted once a week for security updates just like a physical server but never suspended.) The database is on a separate server which is possibly also a VM but again, it is enterprise grade and is never suspended.
Yes, I went through the list of items on post 22633. I did notice on the step 5 that the query SELECT COUNT(*) FROM sgnotify.dbo.events; is still showing 7 even though I cleared out event details and restarted the Vault Notification App Pool. (SELECT COUNT(*) FROM sgnotify.dbo.eventdetails; shows 0) I'm not sure if that is pointing to a problem but it is different from what is expected.
I didn't go through all of the SQL server housekeeping items for a few reasons but I looked at all of the other items. (Performance is fine once I can get in, we had no trouble with Vault 6 with the same SQL server.)
Frankly, even if our SQL server was slow, the Vault client ought to either eventually load or else give a timeout error.
Thanks,
Matthew

[jclausius]

Well, if you checked those things, then let's see if something shows up in the client side logging.

Let's start with a simple log. Start a Vault client, as soon as the UI starts, hit "Control Alt Shift F12" (See viewtopic.php?t=1534) to enable logging. Hopefully this generates some information in a log file. Send that client log file to 'support AT sourcegear DOT com', and hopefully something there can shed some more light on the situation.

[Matthew]

Jeff,
I have found that enabling logging causes the problem to go away. I tried it dozens of times and it would only freeze up when I failed to hit Ctrl-Alt-Shift-F12. There were a couple of times when it paused for 5+ seconds when I had logging enabled but I cannot guarantee that this is the problem we have been seeing since it came out of it.
Here are the 3 events before and after the pause:
6/27/2017 1:26:01 PM <repositorysearchview>: [Main:1] New active repository is different, clearing results
6/27/2017 1:26:01 PM <repositoryexplorer>: [Main:1] refresh requested updateKnown is False
6/27/2017 1:26:01 PM <repositoryexplorer>: [Main:1] refresh requested updateKnown is False
6/27/2017 1:26:08 PM <busy>: [GUIClientWorkerThread:4] Setting GUI to busy from DisconnectFromServer
6/27/2017 1:26:08 PM <eventengine>: [GUIClientWorkerThread:4] Event fired: VaultClientOperationsLib.ConnectionStateChangedEvent
6/27/2017 1:26:08 PM <connection>: [GUIClientWorkerThread:4] Logout started.
One additional reason why I am not sure if this is the same problem: I only got these pauses when loading our regular repository which has data in it. When I tried loading the "initial repository" which has no data I could never get it to pause. However, when I load "initial repository" without logging enabled it will freeze up ~50% of the time just like our regular repository.
Please let me know if you have other ideas for the logging.
Thanks,
Matthew

[jclausius]

Can you post the <startup> section of VaultGUIClient.exe.config found in the user's installation directory?

Also, from the GUI Client (no need to log in), Help -> Technical Support. Can you copy the information from there? Perhaps it is a .NET mismatch problem as the GUI client does best when .NET 3.5 full client framework has been installed.

[Matthew]

Here it is:

Code: Select all

<startup>
	<!-- Placed in order of preference -->
	<supportedRuntime version="v2.0.50727"/>
	<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0,Profile=Client"/>	
</startup>

[jclausius]

Let's try this:

a) Make a copy of VaultGUIClient.exe.config.

b) Edit the original with the following changes (reversing the order of the runtimes)

<startup>
<!-- Placed in order of preference -->
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0,Profile=Client"/>
<supportedRuntime version="v2.0.50727"/>
</startup>

c) Retry

Any change?

[Matthew]

I think that did it! I just tried closing and reopening several times without a problem!
That is interesting, because that is sort of like step 2 in that KB article viewtopic.php?f=13&t=22633 but opposite. When I looked at that step I found that .Net 2.0 was already on top so I didn't try reversing it.
I'll try this on all of the computers that were experiencing the problem.
Thanks!
Matthew

[jclausius]

That KB article was written with the intent that .NET 2.0 or .NET 3.5 is installed on your client machine, which was probably the case a few years ago. From your screen shot it doesn't appear as if that was the case. So reversing the ordering or installing .NET 3.5 was my next suggestion.

Hopefully this resolves the problem.