folderbrowsermoderndialog reverting to non modern on Win 10

[RobBrown]

Good to know!

I deployed the new version with the changes to the one user experiencing the issue and it turns out the dialog is not the modern version at all now that I had the chance to sit down with them.

Referencing my original screenshot, thats the dialog they get 100% of the time. The issue they reported is that sometimes the InitialDirectory is not working but the dialog itself remains the same which is new information.

It does seem to pull the InitialDirectory though but not in full. Where I have the initial directory set to \\Server\path\$MoveRegionPath, using my previous example, they get the window opening up to \\Server\Path, one level higher than expected.

As this user is on Windows 10 Enterprise, I find the behavior quite odd. So far none of the other 4 Windows 10 machines I have personally ran the app on has this issue.

Any other suggestions? Perhaps a .net problem on the users computer?

[jvierra]

If they do not have access to the folder then this is what will likely happen.
We cannot troubleshoot this for you. You will have to do some troubleshooting to understand what is happening. Without a clear understanding of the failure mode there is no way to fix it.

[RobBrown]

So it turns out a few users are now reporting this problem upon further review.

Furthermore, I created a simple test app that just has a folderbrowserdialog and folderbrowsermoderndialog. On the users computer with the reported problem, both buttons work as they should.

Within my app, the problem persists. I also created a new "folderbrowsermoderndialog2" along with a new button that simply just opens the dialog and nothing else and the same issue persists.

There appears to be something within my app triggering the issue, but only on some machines. I'm really not sure how to troubleshoot this without taking out chunks of code bit by bit, compile, copy to affected users computer, run, test and repeat. Any better options? What code could possibly impact this?

The form with this issue is 2500 lines of code. There are also 5 other forms and the global.ps1 file that are 100-500 lines each.

Thanks

[jvierra]

Compile a list of the machines and the problems. Try to determine what on those machines that fail is different from the systems that do not fail.
Old programs that alter the se4ssion may be able to impact this. Something that alters the path or an assembly in the path that should be in the cache may alter this behavior.

Unfortunately there is no way for us to troubleshoot this kind of intermittent issue.

You can place a dump command in the script and have to create a crash dump for analysis.

Be sure you are not constantly reloading the dialog. The dialog should be loaded only once when the form is created and before it is shown. These dialogs discover the parent that is calling them and that may alter the behavior.

I would place one dialog crating into globals and just call that whenever needed. There is no need for multiple objects and we normally don't create them this way. In C# I just crate them on the fly and let them get removed when the function is exited. I may also wrap the dialog in a function that sets the defaults the way I need, gets the folder and exits rem0oving the dialog from memory.

Out of all of the above you may discover something new that will help you to understand what is causing your odd issue.

[RobBrown]

Understood. Appreciate the insight.

[RobBrown]

New development after a lot of troubleshooting.

The issue is being caused by using Alternate Credentials > RunAs User in the Output Settings when packaging. We use this to give the app extra rights to file share on the network that the user would normally not have so its a requirement of the app.

I stripped the app down to 1 form and a single button which has this issue only when using alternate credentials. I then went back to the full app to replicate the problem which has consistent results.

The question now is, how can this get resolved?

Thanks

[jvierra]

Without a sample of the code that causes this there is really no way to manage this. The issue is now more clearly that the path you are setting is unavailable to the code for some reason. If it is intermittent then it is most likely that it is a network issue. Be sure you are carefully testing the code and trapping all errors.

Intermittent says that the code is working and either there are alternate paths through the code, A missing or out of scope variable or external network issues. There is no way for us to guess at this or test it.

[RobBrown]

The issue is not intermittent, it is consistent on the few computers who are reporting the problem.

The issue occurs 100% of the time on these machines when using the alternative credentials.

[jvierra]

Then the issue is obviously easy to isolate since you can repeat it. Now isolate the smallest piece of code that can exhibit this failure and analyze what is happening.

It can be caused by a bad domain join or a network/netcard failure. I have seen similar things many time. Isolating the smallest code that can cause this will also eliminate subtle coding errors. Be sure it is not isolated to specific accounts on the failing system. Account corruption can cause all manner of bad behaviors.

The issue is not a scripting issue. It is s system or network issue.

[RobBrown]

This is the only code now.

Code: Select all

$Login_Load={
}

$button1_Click={
	if ($folderbrowsermoderndialog1.ShowDialog() -eq "OK")
	{
	}
}

The problem persists on a few computers but only when using alternative credentials.

This doesnt appear to be a code issue on my end but rather a problem with this feature in PowerShell Studio related to something within the OS. If you can provide some details on how I could possibly troubleshoot this id be happy to do so.