It is frustrating to see workaround/fixes doesn’t work at customers end, with same environments
on which support replicates. To add fuel to the Fire, our tools too don’t show up big expected
results when client is showing issue :(
Towards last couple of months , I have seen this recurring issues of DLL loading, not working
as expected, .NET security permissions on code executions etc.
In one of scenario, the application using .NET DLL, fails to run at customer while
executing a particular process. Application calls a process from .NET DLL to run on a context
menu. At customer it fails to run, even DLL entry points seems not reached. Locally one can run
without issues, but at customer its restricted, the paths are on application server. Also this application uses partially signed DLL's , instead of strong names (placed in GAC) which makes things more painful for debugging.
Now most of relevant investigation being done including following :
1) DLL registered with regasm on path (app shared)
2) Full admin rights on shared path
3) Fulltrust granted to .NET code on shared path
4) Removed any unwanted conflicting paths of DLL's from registry, where CLSID for the DLL was
registered.
5) Fusion log viewer shows same paths are been picked successfully from where it has to.
Another hitch here is that, there is nothing such a flag / return value to check if DLL's are
registered successfully. So either one has to manual scan registry hive or code to check if
DLL's instance can be used to create an object. Both are painful. Even legacy DLL registration which internally calls DllRegisterServer, has no way to check if registration got successful. See this blog.
Nevertheless, one can debug to attach running process to a debugger to check DLL loading/paths
etc, or much easier, I would say is Sysinternals Process explorer, or another tool I saw was
from Nirsoft's RegDllView.exe. For RegDllView, from my testing, I could not see called DLL's
instantly being displayed, but for procexp.exe, I am 99% sure it should work. So just went ahead
launch my application , called .NET DLL, and ran procexp.exe, locate the app.exe from list of
processes. User View menu to check lower pane, then use View->lower pane view->DLL's.
Now click on app.exe, at the bottom you will see list of DLL's loaded and information like
version, path, manufacturer etc. I think this is a clear win here. See process explorer in action below...
on which support replicates. To add fuel to the Fire, our tools too don’t show up big expected
results when client is showing issue :(
Towards last couple of months , I have seen this recurring issues of DLL loading, not working
as expected, .NET security permissions on code executions etc.
In one of scenario, the application using .NET DLL, fails to run at customer while
executing a particular process. Application calls a process from .NET DLL to run on a context
menu. At customer it fails to run, even DLL entry points seems not reached. Locally one can run
without issues, but at customer its restricted, the paths are on application server. Also this application uses partially signed DLL's , instead of strong names (placed in GAC) which makes things more painful for debugging.
Now most of relevant investigation being done including following :
1) DLL registered with regasm on path (app shared)
2) Full admin rights on shared path
3) Fulltrust granted to .NET code on shared path
4) Removed any unwanted conflicting paths of DLL's from registry, where CLSID for the DLL was
registered.
5) Fusion log viewer shows same paths are been picked successfully from where it has to.
Another hitch here is that, there is nothing such a flag / return value to check if DLL's are
registered successfully. So either one has to manual scan registry hive or code to check if
DLL's instance can be used to create an object. Both are painful. Even legacy DLL registration which internally calls DllRegisterServer, has no way to check if registration got successful. See this blog.
Nevertheless, one can debug to attach running process to a debugger to check DLL loading/paths
etc, or much easier, I would say is Sysinternals Process explorer, or another tool I saw was
from Nirsoft's RegDllView.exe. For RegDllView, from my testing, I could not see called DLL's
instantly being displayed, but for procexp.exe, I am 99% sure it should work. So just went ahead
launch my application , called .NET DLL, and ran procexp.exe, locate the app.exe from list of
processes. User View menu to check lower pane, then use View->lower pane view->DLL's.
Now click on app.exe, at the bottom you will see list of DLL's loaded and information like
version, path, manufacturer etc. I think this is a clear win here. See process explorer in action below...
No comments:
Post a Comment