Sysinternals Homepage
Forum Home Forum Home > Sysinternals Utilities > Miscellaneous Utilities
  New Posts New Posts RSS Feed - 8.3 style paths for modules when using ShellRunAs
  FAQ FAQ  Forum Search   Events   Register Register  Login Login

8.3 style paths for modules when using ShellRunAs

 Post Reply Post Reply Page  12>
Author
Message
Macromullet View Drop Down
Newbie
Newbie


Joined: 17 September 2008
Status: Offline
Points: 7
Post Options Post Options   Thanks (0) Thanks(0)   Quote Macromullet Quote  Post ReplyReply Direct Link To This Post Topic: 8.3 style paths for modules when using ShellRunAs
    Posted: 17 September 2008 at 4:37pm
I have a .net executable that uses dynamic plugin resolution. The issue I'm having is that when using ShellRunAs I can see in the modules list in vs.net that all modules are loaded with 8.3 paths. When I try to dynamically load an assembly I get exceptions loading dependent types, presumably because the base assemblies are in an 8.3 path location but the dependent plugin assembly isnt. Is there a way to make ShellRunAs launch using long paths vs 8.3/short paths?
Back to Top
molotov View Drop Down
Moderator Group
Moderator Group
Avatar

Joined: 04 October 2006
Status: Offline
Points: 17516
Post Options Post Options   Thanks (0) Thanks(0)   Quote molotov Quote  Post ReplyReply Direct Link To This Post Posted: 18 September 2008 at 3:09am
Hi Macromullet,

Any chance that you're able to provide a simple app and a simple plugin that can be used to reproduce the problem you're having?
Daily affirmation:
net helpmsg 4006
Back to Top
Macromullet View Drop Down
Newbie
Newbie


Joined: 17 September 2008
Status: Offline
Points: 7
Post Options Post Options   Thanks (0) Thanks(0)   Quote Macromullet Quote  Post ReplyReply Direct Link To This Post Posted: 18 September 2008 at 2:34pm
Sure. I'll get back to you. By the way I found out yesterday it only occurs with ShellRunAs. If I use runas /user from cmd.exe my app works fine.
Back to Top
Macromullet View Drop Down
Newbie
Newbie


Joined: 17 September 2008
Status: Offline
Points: 7
Post Options Post Options   Thanks (0) Thanks(0)   Quote Macromullet Quote  Post ReplyReply Direct Link To This Post Posted: 18 September 2008 at 3:05pm
Ok here is a sample app. It's not throwing an exception in this test app but it definitely cant load the plugin, because myInterfaceType.IsAssignableFrom(myImplementationType) returns false. That may be leading to the errors in my primary app.

The test app is here: uploads/20080918_150426_TestShellRunAs.zip

Usage:
0. Make sure it's in a path with long folder names that will be changed to 8.3 if any call to GetShortPathName were to be made.

1. Run it without shellrunas. Notice how you can click load plugin and it will show you the implementation plugin that implements IFoo
2. Run it with shellrunas. Click the button. Notice how it no longer shows the plugin messagebox.
3. The launch debugger just calls system.diagnostics.debugger.launch() because that's how I debug case #2. I just run the app using shellrunas in windows explorer then click launch debugger and attach to my open vs.net session.

Also, in vs.net notice how in the modules list the paths are changed to 8.3 paths. That's what causes the issues as far as I can tell. I think it has to do with .net assembly binding.
Back to Top
molotov View Drop Down
Moderator Group
Moderator Group
Avatar

Joined: 04 October 2006
Status: Offline
Points: 17516
Post Options Post Options   Thanks (0) Thanks(0)   Quote molotov Quote  Post ReplyReply Direct Link To This Post Posted: 18 September 2008 at 4:48pm
I am unable to recreate what you report.  I right-click the TestShellRunAs.exe program file, choose "Run as different user...", enter credentials in the prompt presented by ShellRunas, and the app runs.  I click the "Load Plugins" button, and I am presented with a messagebox:
Quote ---------------------------

---------------------------
Found Plugin: c:\sra\this is a long folder name\testshellrunas\testshellrunas\bin\debug\TestShellRunAsPluginImplementation.dll
---------------------------
OK  
---------------------------

Daily affirmation:
net helpmsg 4006
Back to Top
Macromullet View Drop Down
Newbie
Newbie


Joined: 17 September 2008
Status: Offline
Points: 7
Post Options Post Options   Thanks (0) Thanks(0)   Quote Macromullet Quote  Post ReplyReply Direct Link To This Post Posted: 18 September 2008 at 7:36pm
That is so bizarre. It happens for me every single time. Are you running it in a directory that has a long path?

I'm running ShellRunAs v1.01 on Vista Enterprise Edition SP1 x86
Back to Top
Macromullet View Drop Down
Newbie
Newbie


Joined: 17 September 2008
Status: Offline
Points: 7
Post Options Post Options   Thanks (0) Thanks(0)   Quote Macromullet Quote  Post ReplyReply Direct Link To This Post Posted: 18 September 2008 at 7:38pm
Nevermind about the long path. I see you are using one. What about an OS difference? Can you think of anything else that would contribute to it? Where is ShellRunAs actually located on your system?

In mine its in C:\Users\myusername\Downloads
Back to Top
molotov View Drop Down
Moderator Group
Moderator Group
Avatar

Joined: 04 October 2006
Status: Offline
Points: 17516
Post Options Post Options   Thanks (0) Thanks(0)   Quote molotov Quote  Post ReplyReply Direct Link To This Post Posted: 19 September 2008 at 5:00pm
It worked for me because I was using a system where [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation] was set to 1.  Indeed, the issue seems related to ShellRunas' use of GetShortPathName to get the path of the file to pass to CreateProcessWithLogonW.

It does seem that IsAssignableFrom is failing for some reason.  Perhaps, some issue there with use of the 8.3 name?

Changing dllName to be the short path for the DLL does not change the outcome.

The problem seems to be a side effect of the way ShellRunas works since directly launching the program using the short path (or even just the 8.3 filename for the program, with the rest of the path in its "long" form) results in the same behavior.



Edited by molotov - 19 September 2008 at 5:03pm
Daily affirmation:
net helpmsg 4006
Back to Top
Macromullet View Drop Down
Newbie
Newbie


Joined: 17 September 2008
Status: Offline
Points: 7
Post Options Post Options   Thanks (0) Thanks(0)   Quote Macromullet Quote  Post ReplyReply Direct Link To This Post Posted: 19 September 2008 at 5:12pm
I don't seen any indication that CreateProcessWithLogonW requires an 8.3 style path, as long as it's enclosed in quotes, which would seem to mitigate the need for the call to GetShortPathName

I think the IsAssignableFrom issue is by design. In my case what I saw was that the interface assembly was actually loaded twice, presumably once by the main form (using the 8.3 style path) and another time by the implementation assembly (using a long path). The interface reference is 8.3, but the implementation reference is in a long path, but it's bound to the long path interface reference, because it didn't see the 8.3 reference because the path was different so it looked again in the long path and found it and bound to that.

Just a hunch though.
Back to Top
molotov View Drop Down
Moderator Group
Moderator Group
Avatar

Joined: 04 October 2006
Status: Offline
Points: 17516
Post Options Post Options   Thanks (0) Thanks(0)   Quote molotov Quote  Post ReplyReply Direct Link To This Post Posted: 19 September 2008 at 5:17pm
Quote I don't seen any indication that CreateProcessWithLogonW requires an 8.3 style path, as long as it's enclosed in quotes, which would seem to mitigate the need for the call to GetShortPathName
Neither did I.  Yet, as it is more work to call GetShortPathName than not to, one might assume there is some reason.  I cannot say what that reason may be. Embarrassed 

Have you checked the implementation of Type.IsAssignableFrom?  You might debug into it to attempt to see which specific condition that is checked, is failing.
Daily affirmation:
net helpmsg 4006
Back to Top
 Post Reply Post Reply Page  12>
  Share Topic   

Forum Jump Forum Permissions View Drop Down