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.
Related
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?
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 am experiencing an issue with an application that is attempting to access Quickbooks in blind mode (i.e. Quickbooks is not running). In short, I have a simple C# application that synchronizes information between a Quickbooks company file and SQL database on a web server to allow customers to make payments toward invoices online. The UI for the application only has one button and a few other settings so, I modified the code so that it can be run as a scheduled task in the middle of the night. Unfortunately, this has been much more trouble than I anticipated.
First, I could not get it to run through the task scheduler or an elevated command prompt. Then, I came across a post that stated that there is a bug in the SDK when attempting to access Quickbooks via the QBSDK if the host is a terminal server with multiple sessions. The temporary solution was to make sure that Quickbook is running on the session that the job is running on to prevent it from trying to attach to another session. So, I made sure that Quickbooks is loaded but, NOT logged in to a company file. While this solution works if I try to run my application from an elevated command prompt it still does not work when the job is launched from the windows task scheduler. I am not logged into the server remotely now but, the error message states something about not being able to open a session because there is a modal dialog box open. I will modify the post to include the specific error message as soon as I am able to connect to my client's server. Quickbooks is open on the session that is trying to run as a scheduled task and I am able to run the application from an elevated command prompt. Can someone please offer any suggestions or feedback about how I might go about solving this problem? Thanks in advance for your help!
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"
This is the scenario:
I have a service (#1) running as LOCAL SYSTEM, and it will eventually run a process (#2) that updates an application (#3). This process (#2), the updater, must run as LOCAL SYSTEM also, no problem here, since it needs to rewrite some files (#3).
When the updater starts as LOCAL SYSTEM, it will kill any running instance of my application (#3). After the files being update, I need to start the updated application (#3) again as the current logged account.
How could I manage this? Is there anything conceptually wrong in my idea?
UPDATED
The updater kills the app just to replace the files.
I don't think there's a way for the service to get its hands on the WindowsIdentity.Token handle it would need to call the CreateProcessAsUser() API function. Unless the app itself provides it.
There's a better way, you don't have to terminate the app to replace its executable files. All you have to do is rename them. You can then put the updates in place and signal the app to restart itself. Another nice advantage of this approach is that the app voluntarily shuts down (including notifying the user) instead of getting rudely aborted. Clean up the renamed files when you see the process terminated.
If you have access to the user's credentials, you can use Process.Start with a ProcessStartInfo specifying the username and password of the user.
If you don't know the credentials, then I am not sure it can be done.
A work around could be to have the service communicate with your program, asking it to shutdown itself, but before doing so, it should start a seperate tiny program. This should be running in the background, but it will be running with the current user's credentials. When you are finished, ask the background program to start your main program again, then exit.
One problem is knowing the "logged in user". XP and up support fast user switching, where more than 1 user may be logged on at the same time (vista and up support this feature even if the machine is a domain member).
Here is a link to a Raymond Chen blog article discussing the issue: http://blogs.msdn.com/oldnewthing/archive/2006/08/22/712677.aspx