+1  A: 

Could it be related to the question: Why does my .NET application crash when run from a network drive?

That your .net application has other rights on the network share than on your local disk. Updating to 3.5 SP1 will normally remove this issue. Otherwise, check the policies for remote code for .net.

Also you could try an other non .net application (procmon for instance) which required elevation to put it in the same dir and see what happens.

Davy Landman
I did have to patch all the user machines to 3.5 SP1 to get the app to even launch from the network share. I've just tried your suggestion, running procmon from the share, and the same thing happens. Generic icon. So, it appears this might be a limitation of Windows?
Will Rogers
it might be a feature of UAC, or a policy thing? I've just tried that, and indeed, UAC on a network location does not show the normal icon.
Davy Landman
+1  A: 

Apparently it's not something with .net, but with UAC.

I've reproduced the behavior by placing procmon from systinternals on a network share and saw the same difference.

Maybe it has something to do that when switching to an elevated session another user is used. The network mapping is done on the general user, so in the elevated session the application could not be found and therefor it's not possible to display the icon?

You could try to do the following to force the connection to be valid on in the elevated session:

  • start an elevated command promt
  • net use \\your-network-location\share /user:<username> <password>
  • now go to start->run and start \\your-network-location\share\procmon.exe(to be on the safe side avoid a mapped drive) and see if the UAC prompt improves?
Davy Landman
This process doesn't seem to make any difference.
Will Rogers