AppGuard 3.x 32/64 Bit

It appears that everything is contained in that one DOS folder located at c:\ so I don't really get it either. However, I tried Pete's suggestion of moving that folder to Program Files and that seems to have corrected it.

 

They should be guarded as well.

 

If you send the events that you are seeing for your "trusted applications" to AppGuard Support (AppGuard@BlueRidge.com) when running in high we can see if we can recommend policy tweaks.

A single license is good for 3 PCs.

 

It's good to know that moving the folder to Program Files worked.

I still don't understand why AppGuard should have treated a folder outside of the user profile as being in user space though. It's because folders that are not part of the user profile form part of system space that causes the issue with guarded applications running under Sandboxie not being able to write to the sandbox when the sandbox container is in its default location of c:\sandbox.

I've got a folder under c:\ that contains an old DOS program. AppGuard treats it as system space on my Windows XP SP3 system, and allows the program to launch from it, so I don't know what the difference is in your case. Maybe Barb_C can explain it.

 

@Pegr

Well, it looks like I may have spoken too soon. That DOS program still is not working for me, but neither is Pete's suggestion of moving it to the Program Files folder. At first I thought it was, but after trying it again, it wasn't.

It's all kind of giving me a headache just trying to figure it out. Because I don't use this program every day, I think I'll just set the protection level to Medium when I need it. Right now, it seems like the easiest solution .

 

I can't make any since out of it, but it's good to hear! It seems to be something specific to your system.

 

Looks like I replied too soon. You should follow Barbs advice, and start a ticket with BRN. Let us know what the issue was when you figure it out. Its possible there could even be a bug specific to your machine that has not been seen here. It's just a possibility, but i'm not saying that is the case. I'm interested in discovering the cause on this one myself though.

 

Where can I find the Events log that Barb C asked for?

The only other thing I can think of is that I use Karen's Replicator to backup the data file in that DOS program to a usb external HDD. But I can't see where this would have an effect on anything.

 

Just double click AG's tray icon, and it will open the window where events are located. The even list is just below the protection level slide bar. Right click there, and choose save as. Then save it somewhere you will be able to find easily.

 

Did she ask for the policy file? Was you able to find it?

 

Oh that one. I thought maybe she meant the logs in Windows Event Viewer.

 

I'm sorry it still isn't working the way you would like - that's frustrating.

Systems sometimes do exhibit strange behaviour. For example, on my system if I use the option within Internet Explorer to Delete Browsing History, I get the following AppGuard alert: Prevented process <ntshrui.dll - c:\windows\system32\rundll32.exe> from launching from <c:\documents and settings\administrator>.

ntshrui.dll is located within system32 so it should not be launching from user space. I assumed this was caused by a bug in AppGuard until I used Sysinternals Process Monitor to track what was happening. Process Monitor confirmed that ntshrui.dll was indeed trying to launch from user space. Although inexplicable, it appears that AppGuard was responding correctly.

I know I've said this before but Sysinternals Process Monitor might enable you to see why AppGuard thinks this program is trying to launch from user space. If you knew exactly what was going on, you might be able to come up with a permanent workaround without having to alter the protection level every time you want to run the program. Just a thought.

 

I was just looking myself to see if AG saves past event logs to the disk somewhere. If AG does then I do not know to which directory it saves them to. I guess the user must have to manually save them each time since AG does not save them automatically. I see no option to configure AG to automatically save event logs.

 

Just ran across another DOS program in the same location that I use on occasion. The same thing happens. I noticed in both cases the file that's being opened is a *.pif file. Not even sure what a pif extension is or if it matters, but maybe that's why I also get an error message on my desktop when it's blocked that says "*.pif is not a valid Win32 application."

 

PIF = Program Information File. You can read about them here: http://en.wikipedia.org/wiki/Program_information_file

I don't know what would be required to get AppGuard to work with a .pif file. It's a hangover from the DOS days so maybe AppGuard doesn't support them. I run my DOS program executable without using a PIF. Have you tried executing your DOS program without using a PIF to see if it will run?

EDIT: The above is incorrect. My DOS program is executed via a shortcut from system space. Shortcuts to DOS programs are automatically created as .pif files, which are supported by AppGuard as just another type of executable file.

 

AppGuard logs its events in the application section of the Windows Event Log. The Windows Event Viewer can be used to inspect the log and to create backups.

 

I think the PIF is the problem. I ran the exe file directly from the folder and it opened just fine - AG didn't interfere at all. But for some reason, when I create a shortcut from the exe, the shortcut is converting it to a PIF and I don't know how to get around that.

 

Creating a shortcut to a DOS program automatically creates a .pif file. What I don't understand is why a shortcut to a DOS program won't execute from system space on your machine with the AppGuard protection level set to High when it does on mine.

I assume that your .pif file containing the shortcut is located in system space. It's not enough for the .exe file to be in system space if the .pif file used to launch it is in user space. For example, the shortcut should be able to run from Start All Programs but won't run from the desktop with the AppGuard protection level set to High. The .pif file itself is considered to be an executable by AppGuard.

Assuming that the .pif file is in system space, and that's not the issue, it looks like you will need to continue temporarily reducing the protection level to Medium to run the program, as you have been doing.

It might be worth opening a support ticket with Blue Ridge Networks to see if they have any suggestions.

 

The shortcut is on my desktop. I don't know what that's considered (user space, I assume). It seems to be that one of the ideas behind a shortcut is to put it in a location that makes it convenient to use, so that's what I've done.

What do you suggest I do to move it and still make it accessible?

 

The desktop folder is located within the user profile of the current user logged on to Windows, and therefore lies in user space.

In order to move the shortcut to a system space location that makes it convenient to use, right-click on the Start button on the taskbar and select Open All Users then move the shortcut to the Programs folder. Unlike the current user profile, which is in user space, the All Users profile is in system space. You should now be able to run your program via Start->All Programs without interference from AppGuard.

Alternatively, you could remove the desktop from user space protection by adding an exception in the Guarded Apps tab for the desktop folder - located within the current user profile within c:\documents and settings\ - and setting the Include flag to No. That should also work but I'm not sure it would be advisable from a security perspective to exclude the desktop from Guarded Apps protection. The first method is safer.

This is a restriction that is peculiar to DOS programs because, unlike Windows program shortcuts, files with a .pif extension are executables in their own right.

 

The events are save in the Windows Application Event Log provided the "Log" checkbox is checked on the Alerts GUI.

 

A shortcut on your desktop is fine. AppGuard will not interfere with it. AppGuard should only block the launch if the application itself (not the shortcut) is located in user-space. If the application is located on the system volume (usually C: ) outside of the user profile directory, then it should launch (the C: drive for the most part is considered system space). If the application is located on another drive then it is considered to be user space and then user-space rules will be applied.

When you say the application is not working, can you be more specific? Is it launching at all and then failing? Or is AppGuard preventing it from launching all together. If it is failing, how is it failing - crashing or not operating properly?

Since you mentioned that this is a DOS program, I assume that you are running from a command prompt. AppGuard automatically guards cmd.exe and if your application is trying to write to system space (i.e. the directory where it is located) or to certain registry keys, AppGuard will block. But that does not explain why your application works in medium since cmd.exe is also Guarded in medium.

I have a couple ideas on how to make your application work without reducing your protection level, but I need to see the AppGuard blocking events. Make sure your Alerts are set to report status for all events. Then put AppGuard in high protetion level and make your application fail. You should see several blocking events in AppGuard's GUI. Select all events, save them and send to me at AppGuard@BlueRidge.com (or post them here). Thanks!

 

PEGR, your instructions are correct on how to move the shortcut, but there is really no reason to move the shortcut to system space. A shortcut on the desktop will work just fine with AppGuard as long as the program that the shortcut points to is located in system space (or is allowed by the user-space protection policy). I hate to correct you because you always provide such excellent information regarding AppGuard (and ofter expain things better than I can).

 

Hi Barb,

DOS shortcuts behave differently to Windows shortcuts in this respect. I tested this myself and was able to reproduce the symptoms that TomAZ is describing. If the .pif file is located on the desktop then AppGuard blocks it at the High protection level but allows it at the Medium protection level. The blocking message itself clearly states that it is the .pif that is denied from launching from user space.

Moving the .pif file to Start->All Programs solves this issue, as does making an exception for the desktop to exclude it from user space by setting the Include flag to No. I believe that Start->All Programs is the safer option and is what I do to run an old DOS program that I still use.

With regards to Windows .lnk files, you are of course correct. Providing the executable that the shortcut is pointing to is in system space, there is no need to do anything.

Kind regards
pegr