I am building a winforms app that inspects processes as part of its routines. I am only getting a few details from the running processes, such as MainWindowTitle, name, executible etc.
I see on some processes this cant be accessed. I know system processes cant be inspected in detail, but it seems like the ones I cant access, being normal processes, happens because they are being run as Administrator.
I run my visual studio as Administrator, and if I don;t run my compiled app as Admin, I simply cant get any details from the Visual Studio process.
On the flip side, with Management Studio for instance, I don't specifically run it as Administrator, but if I don't run my compiled app as Administrator, I cant inspect the Management Studio process.
Does Management Studio somehow run elevated, without bugging me? (That's what I want to accomplish in my own app)
What I am looking to do so far:
I have looked at the possibility of running my app elevated using a manifest, but I don't want my whole app to force Admin privileges access on to someone that does not like that..
Is there a way for only the routine that inspects my processes, to run elevated, but not to bug the user each time that it runs (Several times/minute).
Can I run my process inspection routines in a separate thread, and elevate that thread without bugging the user..
Can I do something similar to Task Scheduler, where you can specify the admin account to use in the (Run task as) section? This way the user can be prompted for their password (preferably by the system), and not be bothered the next times it runs.
Any ideas on the subject?
Related
I have a .Net application that's reporting hangs in the Event Log. The events say "Application Hang" with no usable details to go by.
So I whipped up a C# console app that uses the ClrMD library. But the caveat is this application is being published as a RemoteApp. When I try to attach ClrMD to the users' process I get this error:
Microsoft.Diagnostics.Runtime.ClrDiagnosticsException: Could not attach to process. Error 0.
This is not surprising since I'm logged into the server as Administrator and they are in their own RDP session with a different user.
So then I decided to impersonate the user they are logged in as thinking if I run my ClrMD app as them, it will have access to that process. This gave me a different error:
Microsoft.Diagnostics.Runtime.ClrDiagnosticsException: Could not attach to process. Error 1008.
I can't seem to find any clues as to what 1008 means to know where to go from here. I realize I'm probably trying to do something that's not possible.
Has anyone gotten ClrMD to attach to another user's process?
If not, are there are debug tools out there that can attach to other users' processes?
If not, have people used ClrMD in within production and how would I know the app is hung to know when to trigger a ClrMD dump? Just monitor the UI thread in another background thread?
Had / have same issue. Running elevated as admin on a server via a console app didn't work. But it does work if run through PowerShell or Visual Studio itself with elevated permissions. The debugger requires Admin privs to connect live. Adding a manifest, etc didn't seem to help when running as a console.
I have a console application that performs some data work and then closes. If I run the executable manually it opens a command prompt, runs the program, and closes. No issues at all regardless of what Microsoft OS I'm using.
However, if I attempt to run the program as a scheduled task it fails on one specific server running Windows Server 2008 R2. It works as a scheduled task just fine on other servers, including another Windows Server 2008 R2 box in the same building. Unfortunately this one server is the server it needs to run on. I've tried adding logging, writing to the event logs, executing the application as an administration, forcing 32 or 64 bit, and launching it as a separate launch from a .bat file. Nothing. The program isn't crashing, it is just never opening.
Does anyone know what may be causing this? I'm at a loss and I don't know what to do.
Edit: I created a test .bat file that just launches a command prompt to see if it would open a command prompt window. It does not. The other tasks seem to run fine though.
Edit #2: I have been researched this and something that has come up is to set the task to enable with desktop. I can't find that option nor can I think of a reason why it would fix this issue but it seems to keep coming up.
After a bit of fiddling around this is what worked for me. When you point to the console application in the actions Tab, ensure that you fill in the 'Start in' field with the location where the executable is located even though it says that it is optional. Once you fill that in, it will work.
Is it possible for code to work perfectly on the Administrator profile and not work at all while logged in as another user?
I am building certain applications at work, and while developing, coded and tested while logged on as Administrator. Every application working normally.
Now before deployment, when I execute the same application, but now logged in with a specific user account, I just get the error "Console Application stopped working" etc etc. I have handled all possible exceptions with my own Message Box, but this error is something I did not expect?!
In the exe's, I tried changing setting to "Run as Administrator", no use!
Any help would be much appreciated. Thanks!
PS - There are certain FTP methods I reuse from another class. And by handling all possible exceptions, I mean, I would have a try-catch block for the FTP method, so in case of error encountered after deployment, affected user may call helpdesk and notify the exact error.
Well, its not the right way to go, but right click and run as Admin, works butter smooth. Should I go ahead and modify all executables to - Run as Administrator under Properties->Compatibility??
You should firstly investigate if your application does need Admin rights indeed. A few scenarios that I can think of where an App needs admin rights are writing to protected locations of the system, writing to registry (excluding the areas that the user has rights on). If you think that admin access is not needed, you could always seek other ways to make it work. For example, instead of writing to a protected location, create a directory for you application in the user's application data folder and write to that location.
When you launch the application, if you're running on I believe Windows Vista or higher(7 works this way for sure)
You can Right click on the application and click on Run as Administrator
And yes, Sometimes the application won't work if you're not running as an administrator. For instance, If it's trying to change files in a protected location.
There are other variances that can cause your program to not work, For me, "Console Application stopped working" normally means that you don't have the right version of the .net framework installed, but it can mean any number of things.
I have one major problem with my app. I have an app & updater as a separate exe files. When an update is available, updater does the update, and on process completion it starts my app. The main problem is - app is installed in program files folder, so updater need UAC admin privileges, and that's ok, but when I need to run my app updater needs to run it as a normal user, because if it's run as an administrator drag and drop doesn't work (not an app problem, UAC blocks it). I've tried several different solutions, and even this one:
How to run NOT elevated in Vista (.NET)
It haven't helped me - my app is run as an administrator.
You'd better avoid starting a non-elevated process from an elevated one. It's tricky part and error-prone.
This approach is better:
Your updater initially starts as non-elevated application, and its manifest has asInvoker level.
When it starts, it restarts itself with elevated privileges using runas verb, and passes a command-line parameter to indicate it. This instance performs the update and returns.
Here comes the non-elevated updater again, and starts your application with the same non-elevated user token that started the first instance of updater in step 1.
Pretty simple and robust.
Look at this post on how to Enable Drag and Drop for an Elevated process. Even though it says MFC app you can cll those Windows API in Any app I suppose
https://helgeklein.com/blog/2010/03/how-to-enable-drag-and-drop-for-an-elevated-mfc-application-on-vistawindows-7/
I found this nice snippet of code online:
rkApp = Registry.LocalMachine.OpenSubKey("SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run", true);
Which runs great but alas on windows 7 and vista I suspect, it crashes cause it doesn't have permission to write there.
So then I research (on stackoverflow of course) how to avoid this, quickest method:
rkApp = Registry.CurrentUser.OpenSubKey("SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run", true);
Simple enough! Though there is two issues remaining. One is with both methods (on a XP Box that is), the program thinks its relative path is somewhere in the C:\windows folder now...so I.e. it won't find my path relative help files etc. The second issue is, on windows 7, my program won't startup until I log in. I want it to start up in the background if possible before anyone logs in.
Its a simple .exe that hangs out in the systray when its running. I didn't want to create this monstrosity of an installer to get around these admin and pathing issues.
I Think I would have to create it as a service (no clue how to do that) to get it to start up when the machine reboots before anyone logs in. Secondly to do that I am sure I have to figure out the admin privileges, and since I don't want to have to approve the program to run every time it starts up it sounds like I would have to figure out its admin privileges during install time, but alas no installer.
So just curious what routes I might take to get this to work. I can even suffer it coming up only after when the user logs in, but my current methods that work this way really screw up the pathing of my program since it tries to write stuff out to a new directory (not the one I originally started the EXE from). Etc...and I have no clue how to go about fixing that pathing issue.
It sounds like you need two programs here.
You can't have an application run in the system tray and run prior to login. The system tray doesn't "exist" until the user logs in and has a valid desktop.
The normal way to handle this is to make two programs. First, create a windows service that does the bulk of your work. This will run on startup, and be independent of any user logins.
Then, make a user mode application which uses IPC to communicate with the service. This can run on login, and "talk" to the service remotely, thereby providing your system tray requirements.
If you want your program to start as a service before anyone logs on, then it's going to need to be installed and run as an admin user. There's not getting round this fact.
There's a Microsoft Knowledge Base article on creating a service which should get you started.
There's a project template for a Windows Service installed by default in Visual Studio 2008:
"File > New > Project > Visual C# > Windows > Windows Service"