I always get this when I try to open WillowTree, which always crashes immediately upon starting:
"Description:
Stopped working
Problem signature:
Problem Event Name: CLR20r3
Problem Signature 01: willowtree#.exe
Problem Signature 02: 2.2.1.0
Problem Signature 03: 4d6c17b7
Problem Signature 04: mscorlib
Problem Signature 05: 2.0.0.0
Problem Signature 06: 4a27471d
Problem Signature 07: 349e
Problem Signature 08: 1f7
Problem Signature 09: System.UnauthorizedAccess
OS Version: 6.1.7600.2.0.0.256.1
Locale ID: 1033
"
I'm running Windows 7 via BootCamp on a MacBook Pro. I've replaced the x360.dll file as suggested in another thread. Firewall is disabled. Why is this happening????
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm also having an similar error, though I am running Windows 7 through Parallels Desktop Build 5.0.9376. I too have tried replacing the files suggested in previous threads, and have also tried the 'MacTree' version with no success.
Description:
Stopped working
Problem signature:
Problem Event Name: CLR20r3
Problem Signature 01: willowtree#.exe
Problem Signature 02: 2.2.1.0
Problem Signature 03: 4d6c17b7
Problem Signature 04: System
Problem Signature 05: 2.0.0.0
Problem Signature 06: 4a275e12
Problem Signature 07: 1b38
Problem Signature 08: 75
Problem Signature 09: System.UriFormatException
OS Version: 6.1.7600.2.0.0.256.1
Locale ID: 1033
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This appears to be a bug in Parallels but there may be a way I can work around it if I can figure out exactly what is causing it. I've written some code into the latest experimental revision to provide more detailed information when WT# crashes so I will be able to get some idea of exactly which line of code is causing this problem and see if there is something I can do.
Try to download experimental revision 212 from the experimental files area and run it . When it crashes it should produce more detailed information and write the log to WillowTree#.log in the folder with the WillowTree#.exe application. If you can paste a copy of WillowTree#.log here I will see if I can't do something to fix this problem that prevents Parallels from working.
Experimental revisions are located in the experimental folder in the files area:
You do not have WillowTree# properly installed in a folder that the user has read and write access to if WT# failed to write WillowTree#.log.
Make a subfolder of your My Documents folder, call it anything you want, extract all the files from the zip file into it, open the Windows Explorer (My Computer) and navigate to that folder then click or double-click the WillowTree#.exe icon to run WillowTree#. The user should always have read and write access to his own My Documents folder.
I don't know if that will solve your problem or not, but without WillowTree# being in a folder that you have read and write access to, it can never work. Fix that problem then report back whether you still have an issue or not.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have made a minor code change in experimental revision 222 that I hope will help resolve the issue with Parallels. It appears that Parallels is causing an exception when the application tries to access Application.ExecutablePath. I've rewritten the line of code to try to use another method to find the executable path that perhaps may work. I'll need someone who has had trouble with Parallels to test it and let me know what happens.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've had a little more time to research the issue with parallels and the problem is that the Parallels shared folder feature uses '.psf' for the host name when it shares folders, but '.psf' is not a legal host name according to Windows because it contains a period in it. You aren't supposed to have a period in a host name at all in Windows and if you try to set your computer name to something with a period Windows will not accept it. If you manually try to mount a share with a hostname that has a period Windows will not let you.
It so happens that Application.ExecutablePath in .NET converts the executable file's path into a URI as a way to determine whether the path is to a file or something else so it can demand code access to it if it is a file. The problem is that you can't ever legally create a URI from a path that looks like 'file://.psf/<path>' in .NET because the URI constructor validates the fields and recognizes that the host name is invalid because of the period in it. You can see this by just trying to run a simple line of code like this:
System.Uri uri = new System.Uri("file://.psf/path");
The moral of this story is dont ever use a period in the host name. When I say host name here I mean the equivalent of the NetBios host name or what Windows would call your Computer Name, not a fully qualified domain name that would be returned from a DNS server. Unfortunately this mistake was made in the Parallels folder sharing mechanism, you can't change it as far as I know, and it can interfere with the proper operation of a lot of .NET software including Microsoft development tools.
I hope what I've done to the WT# experimental revision already has made it possible to run Parallels since I no longer try to access Application.ExecutablePath, but I've not received any reports either confirming or denying this. However its possible that other .NET methods also create URIs behind the scenes and if they do then they would fail from UriFormatExceptions too. You just can't legally create a .NET URI from a file from a UNC name (the name used internally in the filesystem) name that specifies .psf as the hostname, so if an application ever attempts to do that you're going to have a malfunction, period.
You also may be able to resolve the issue with some software by mounting your share folder as a drive letter using the Parallels tools so that instead of trying to access '\\.psf\path\file' it'll try to access something like 'Z:\path\file', but if the software ever tries to be clever and resolve the drive letter back to its actual share name instead of just using the drive letter it will probably still fail.
If you want to have shared folders and you can't manage it through Parallels and still have your sofware work right then I'd say it might be time to check out using a different virtual machine software such as VMWare Fusion or VirtualBox.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I always get this when I try to open WillowTree, which always crashes immediately upon starting:
"Description:
Stopped working
Problem signature:
Problem Event Name: CLR20r3
Problem Signature 01: willowtree#.exe
Problem Signature 02: 2.2.1.0
Problem Signature 03: 4d6c17b7
Problem Signature 04: mscorlib
Problem Signature 05: 2.0.0.0
Problem Signature 06: 4a27471d
Problem Signature 07: 349e
Problem Signature 08: 1f7
Problem Signature 09: System.UnauthorizedAccess
OS Version: 6.1.7600.2.0.0.256.1
Locale ID: 1033
"
I'm running Windows 7 via BootCamp on a MacBook Pro. I've replaced the x360.dll file as suggested in another thread. Firewall is disabled. Why is this happening????
I'm also having an similar error, though I am running Windows 7 through Parallels Desktop Build 5.0.9376. I too have tried replacing the files suggested in previous threads, and have also tried the 'MacTree' version with no success.
Problem signature:
Problem Event Name: CLR20r3
Problem Signature 01: willowtree#.exe
Problem Signature 02: 2.2.1.0
Problem Signature 03: 4d6c17b7
Problem Signature 04: System
Problem Signature 05: 2.0.0.0
Problem Signature 06: 4a275e12
Problem Signature 07: 1b38
Problem Signature 08: 75
Problem Signature 09: System.UriFormatException
OS Version: 6.1.7600.2.0.0.256.1
Locale ID: 1033
This appears to be a bug in Parallels but there may be a way I can work around it if I can figure out exactly what is causing it. I've written some code into the latest experimental revision to provide more detailed information when WT# crashes so I will be able to get some idea of exactly which line of code is causing this problem and see if there is something I can do.
Try to download experimental revision 212 from the experimental files area and run it . When it crashes it should produce more detailed information and write the log to WillowTree#.log in the folder with the WillowTree#.exe application. If you can paste a copy of WillowTree#.log here I will see if I can't do something to fix this problem that prevents Parallels from working.
Experimental revisions are located in the experimental folder in the files area:
http://sourceforge.net/projects/willowtree/files/experimental
I downloaded the experimental version of the program and was met with a dialog box, I've included it as an image.
You do not have WillowTree# properly installed in a folder that the user has read and write access to if WT# failed to write WillowTree#.log.
Make a subfolder of your My Documents folder, call it anything you want, extract all the files from the zip file into it, open the Windows Explorer (My Computer) and navigate to that folder then click or double-click the WillowTree#.exe icon to run WillowTree#. The user should always have read and write access to his own My Documents folder.
I don't know if that will solve your problem or not, but without WillowTree# being in a folder that you have read and write access to, it can never work. Fix that problem then report back whether you still have an issue or not.
I have made a minor code change in experimental revision 222 that I hope will help resolve the issue with Parallels. It appears that Parallels is causing an exception when the application tries to access Application.ExecutablePath. I've rewritten the line of code to try to use another method to find the executable path that perhaps may work. I'll need someone who has had trouble with Parallels to test it and let me know what happens.
I've had a little more time to research the issue with parallels and the problem is that the Parallels shared folder feature uses '.psf' for the host name when it shares folders, but '.psf' is not a legal host name according to Windows because it contains a period in it. You aren't supposed to have a period in a host name at all in Windows and if you try to set your computer name to something with a period Windows will not accept it. If you manually try to mount a share with a hostname that has a period Windows will not let you.
It so happens that Application.ExecutablePath in .NET converts the executable file's path into a URI as a way to determine whether the path is to a file or something else so it can demand code access to it if it is a file. The problem is that you can't ever legally create a URI from a path that looks like 'file://.psf/<path>' in .NET because the URI constructor validates the fields and recognizes that the host name is invalid because of the period in it. You can see this by just trying to run a simple line of code like this:
System.Uri uri = new System.Uri("file://.psf/path");
The moral of this story is dont ever use a period in the host name. When I say host name here I mean the equivalent of the NetBios host name or what Windows would call your Computer Name, not a fully qualified domain name that would be returned from a DNS server. Unfortunately this mistake was made in the Parallels folder sharing mechanism, you can't change it as far as I know, and it can interfere with the proper operation of a lot of .NET software including Microsoft development tools.
I hope what I've done to the WT# experimental revision already has made it possible to run Parallels since I no longer try to access Application.ExecutablePath, but I've not received any reports either confirming or denying this. However its possible that other .NET methods also create URIs behind the scenes and if they do then they would fail from UriFormatExceptions too. You just can't legally create a .NET URI from a file from a UNC name (the name used internally in the filesystem) name that specifies .psf as the hostname, so if an application ever attempts to do that you're going to have a malfunction, period.
Parallels recommends disabling personal shared folders to resolve the issue here: http://kb.parallels.com/en/6504
You also may be able to resolve the issue with some software by mounting your share folder as a drive letter using the Parallels tools so that instead of trying to access '\\.psf\path\file' it'll try to access something like 'Z:\path\file', but if the software ever tries to be clever and resolve the drive letter back to its actual share name instead of just using the drive letter it will probably still fail.
If you want to have shared folders and you can't manage it through Parallels and still have your sofware work right then I'd say it might be time to check out using a different virtual machine software such as VMWare Fusion or VirtualBox.