Closed jhoerr closed 7 years ago
Attempted to reproduce on hyper-v with the following build steps: 1) Install Windows 10 v1511 2) Install Kumo client 3.2.4 3) Upgrade to Windows 10 v1607 4) Observe Kumo doesn't work 5) Observe reinstall doesn't resolve issue
However, the client behaved appropriately following those steps. So, I met with Brandon and Tim to further discuss the issue. They are going to build a box with the same sequence that produces the error. They said it would be a few days before they could get it setup, but they would let me know when it's ready.
Last week, I had Brandon attempt to fix the issue by:
However, the issue still occurred.
Also, I feel that I didn't fully understand the problem until watching Brandon attempt to use Kumo on his computer. To better explain the issue, Brandon's machine mounts the virtual drives. He can also navigate through the directory structure of each drive. The mounting dialog works as expected. The issue occurs when Brandon attempts to open any type of file. When checking the error view, we see the "Could not load file or assembly 'System.IO" error after each attempt to open a file in the virtual drive.
So it looks like you've determined that the CBFS drivers probably aren't the root of the issue. That's good progress! Now to figure out what's responsible for the System.IO errors.
After checking Brandon's GAC, I can confirm he has System.IO 4.0.0.0 on his machine.
Fixed in 3.3.0
This error occurs sporadically, but consistently on the machines that exhibit it. It appears that the client can't access .Net framework assembl(ies). We know the framework is installed because we check for that on installation. It appears that the file is present because this is a 'FileLoadException' rather than a 'FileNotFoundException'. It does not appear to be a permissions issue because there isn't a message to the effect of 'access is denied'.
Will fix this as 2.9.5 if it can be root caused to something in the app.