Monday, July 14, 2008

Remotely start applications with WMI & bypass Code Access Security

This article assumes that the reader has an understanding of how to make queries to WMI, has administrative rights on the remote machine & can create a windows service. I am not going to contain any code but I will try to include links to sites that can provide help.


Reasoning (the story)

I needed to install a network monitoring agent on all of our servers. To do this I was using WMI to start a .exe that started and monitored the installation. My application had to check environment variables. Which then caused it to fail because of Code Access Security, even though I had full administrative rights. You can change the systems security policy to allows your program to run if you are allowed, but I figured that it would be more work to get all of the security settings changed. So I came up with a new plan to install a windows service through the Win32_Service Namespace in WMI. So I change the application to a sindows service and it could read the environment variables just fine. Then I removed the windows service through the same WMI Namespace. (I plan on making it a client/server where the server installs, monitors, and uninstalls the client.)

The Steps (super simplified)

  1. Write a windows service. (don't forget the installer)
    Use this service to install applications, or start executables. Also, if you leave this on the remote machine for any period of time you greatley consider the security of it.
  2. Remotley install/remove the service. (I choose WMI)

Thats about it, after your service starts on the machine it can do just about anything it wants, read system variables, start other applications, install programs...


Thanks for reading, please leave a comment to let everyone know how this helped you out.

Thursday, June 19, 2008

Remotely Debug a Running Process with Visual Studio .Net.

Here goes my attempt to explain the process of remotely debugging any application written with C#, VB/Visual Basic or C++. In order to do this, all you will need is Visual Studio .Net Pro & an application with source code available to debug. (VS.Net 2008 Express will do c++ but you still need pro for C# or VB...)

Microsoft's Remote Debugging Monitor
The Remote Debugging Monitor is basically a server that Visual Studio connects to for, well, remotely debugging code... This will need to be running on the remote machine that the process you want to debug is on.

If you have Visual Studio installed on the remote machine. You can start the Remote Debugging Monitor from the start menu by going to: Microsoft Visual Studio -> Visual Studio Tools -> Visual Studio Remote Debugger.

Otherwise, you can copy the needed files to the remote machine & start it over there.
The files you will need are located in the Visual Studio file in the "Common\IDE\Remote Debugger" file.
So copy these files over to the remote machine and start msvmon.exe.

  • mcee.dll
  • msvb7.dll
  • msvsmon.exe
  • msvsmon.exe.config
  • symsrv.dll
  • vjscompee.dll
In order to connect to the Remote Debugging Monitor you will need to be an administrator on the remote machine & both firewalls will need to be turned off.

Getting your project Ready
Now open your project with Visual Studio & put all of your breakpoints in. If you need some time to allow you to connect before a break point will be hit, put in a sleep. I gave myself 25 seconds. (System.Threading.Thread.Sleep(25000);)

It doesn't matter how you start your program on the remote machine but it does matter that your .pdb file is in the same location as the .exe when it's run. The .pdb file contains the information about the code in relation to the breakpoints. So copy your projects .pdb file to the same location of your .exe. It can be found in the projects folder under:\bin\Debug.

Attaching Visual Studio to the remote process
Go to the machine you have Visual Studio running on & go to "Debug -> Attach to Process..." on the task bar. Make sure the Qualifier is the name of the remote computer you are attaching to and that you can connect & view the running processes. If you have problems check out: http://support.microsoft.com/kb/910448

Now start the process on the remote machine, click on it in the Attach to Process window, and click Attach. As soon as the process hits a Break Point, assuming you left yourself enough time to attach before the break. All of the code should appear in your debugger and you'll be able to step through & debug as normal.


Reasoning
I was writing an application using WMI to remotely install an enterprise network capture agent on several hundred servers. I ran into a problem where certain operations or lines of code, didn't have enough security privileges. What I found out is that even if you are an admin on the machine, depending on where your code starts & how it is started, each line is subject to Code Access Security. There are ways around this, (another article to come...) but it turns out that my app was failing because I was trying to gain access to an environment variable. Being able to remotely debug this process made it much easier to find out my error.


Thanks for reading and please leave a comment to let everyone know how this helped you out.

Debugging VBScripts with Visual Studio .NET

How to debug a .vbs or .js file with Visual Studio .Net or Microsoft Script Debugger.

First off, your going to need a debugger... I prefer Visual Studio .NET but you can also use the MS Script Debugger.

First, you'll need a script to debug, so stick this code in notepad & save it to "c:\foo.vbs". Unless you already have your own of course.

'c:\foo.vbs
WScript.Echo "To Debut: Run -> cscript //d c:\foo.vbs"
WScript.Echo

num1 = 5
num2 = 13

'Here's your break point which will send this to the debugger.
STOP

WScript.Echo "num1: " & num1
WScript.Echo "num2: " & num2
WScript.Echo "num1 + num2: " & num1 + num2

WScript.Echo
Set oShell = CreateObject( "WScript.Shell" )
user=oShell.ExpandEnvironmentStrings("%UserName%")
comp=oShell.ExpandEnvironmentStrings("%ComputerName%")
WScript.Echo comp & "\" & user[/code]


Now you can start debugging the .vbs or.js file from Start -> Run or the Command Prompt.

Type:
cscript //d c:\foo.vbs (To use STOP as a breakpoint)
cscript //x c:\foo.vbs (To starting debugging immediately)

As soon as the Windows Script Host hits the STOP that is located after the first few lines, Windows will prompt you to select a debugger. Alternately, you can stick a //x to start the debugger at the start.

I just want to say how happy I was when I found this because manually debugging scripts was a really big PITA. If you have any problems, check out Microsoft's KB article #308364 because it just may help...


Thanks for reading and please leave a comment to let everyone know how this helped you out.

Friday, May 11, 2007

Setting a Priority to Your Processes

If you have a process, application or program that is resource intensive and you would like it to run faster. Windows will allow you to set the priority of that process. By default, the majority of the common windows applications are set to Normal. If you compose an application that sorts through huge amounts of data, takes up tons of memory, is very processor oriented, or you would just like it to run faster. You may want to give it higher priority among the other processes.

Programs with higher priority will always win the fight for the processor. As soon as a program with high priority gets done using some resource and needs the processor again, it will get it. You can think of a high priority process as the fast pass at Disney Land, instead of waiting in line for "hours" you get to jump right onto the ride.

Setting a processes' priority:

  1. Hit Ctrl+Alt+Delete (To go to your Task Manager)
  2. Select the Processes tab at the top
  3. Locate & right click on the desired running process
  4. Set Priority

This will permanently change this processes priority.