How to audit application actions.

[Frank Rizzo]

I have a c# 2.0 winform app that runs under a user account with very
limited rights. The application crashes on some actions (the Send Error
to Microsoft screen) with unauthorized exception.

This is despite the fact that I have try catch blocks around pretty much
absolutely everything. I've tried logging to disk, but it seems to
crash on a deeper level.

The app works fine when run under an admin account.
So how can I audit what the application is trying to get access to and
failing to a degree where it can't even log?

Regards

[Bruce Wood]

On Jan 29, 5:16 pm, Frank Rizzo <[e-mail]:

I have a c# 2.0 winform app that runs under a user account with very
limited rights. The application crashes on some actions (the Send Error
to Microsoft screen) with unauthorized exception.

This is despite the fact that I have try catch blocks around pretty much
absolutely everything. I've tried logging to disk, but it seems to
crash on a deeper level.

The app works fine when run under an admin account.
So how can I audit what the application is trying to get access to and
failing to a degree where it can't even log?

Regards

You need to handle two static, global events that signal uncaught
exceptions. See the following thread:

http://groups.google.com/group/
microsoft.public.dotnet.languages.csharp/browse_frm/thread/
17f2183925c78035/ec669a24ac504841

and here is the MSDN article it referes to:

http://msdn.microsoft.com/msdnmag/is...T/default.aspx

[Frank Rizzo]

Jeffrey Tan[MSFT] wrote:

Hi Frank,

In .Net Winform, we should use Application.ThreadException event as the
global unhandled exception handler to catch all the exceptions in main GUI
thread. In this global unhandled exception handler,
ThreadExceptionEventArgs.Exception.StackTrace property will reveal the call
stack information of the crash exception. You may save it to the event log
or some other suitable places.

I'll do that. Though i am not sure that it will work, because even
though the app is of type Windows Application, all the processing
happens in Program.cs and then the program exits. There are no actual
GUI involved. So in that respect, it is almost like a Console app. The
only reason it is not a console app is that other apps must be able to
kick it off and the users don't want to see the black box quickly appear
and disappear.

However, .Net Winform has set a default global unhandled exception for
Application.ThreadException, which will pop up an error dialog with all the
error information including the stack trace log. Please see the attached
Default_ThreadException.jpg. So, I am actually surprised to see that your
application will pop up a "Send Error To Microsoft" dialog on crash. Note:
this Application.ThreadException event can only catch the exceptions thrown
in main GUI thread.

Yes, I am surprised as well. Getting the crash with the dialog in your
screenshot would be a welcome change - at least I could see the trace.

Based on the description, it seems that you have used big try...catch
clauses to catch the crash exception, but when you are trying to log it to
the disk file, it failed a second time. Because this problem only occurs
under the limited user account, I suspect the second crash during the
logging should be caused by the security issue. In .Net, there are 2 types
of security: .Net Code Access Security and Windows account security.

No, I don't think it fails on logging because I am logging everything up
to a certain point. Then the logging ceases and the "Send to MS dialog"
pops up. Besides the directory it is logging to is totally open to
everyone (i gave everyone full rights).

First, once your Winform application is launched from the local file
system, the .Net CAS will full trust your application, so the .Net CAS
should not cause any problem in this scenario. Then, the most possible
problem is the Windows security exception. Can you tell me which location
your application is trying to log? I suspect the limited user account may
not have enough write NTFS permission to that location(such as
file/directory). So when you are logging to that file, the Windows NTFS
finds you do not have pemission to write to it, and an security exception
is generated. For example, if the log file or the log directory is created
by an Administrator, then the default NTFS security setting over this
file/directory will not allow the limited user account to write to it.

The directory has full NTFS permissions on it.

If my assumption is correct, the solution is either changing the logging
location to a private folder which the limited account have write
permission or changing the NTFS security setting of the location to give
this limited user account proper write permission.

[Jeffrey Tan[MSFT]]

Hi Frank,

Have you reviewed my last reply to you? Does it make sense to you? If you
need any help or have any concern, please feel free to tell me, thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

[Frank Rizzo]

Jeffrey Tan[MSFT] wrote:

Hi Frank,

Have you reviewed my last reply to you? Does it make sense to you? If you
need any help or have any concern, please feel free to tell me, thanks.

Yes, I did, thank you. Meanwhile I found the culprit, one of the files
was losing it's permissions somehow during the installation (will have
to talk to the installation folks). Changing that fixed the issue.

Thanks again.

>
Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

[Jeffrey Tan[MSFT]]

Hi Frank,

Thanks for your confirm!

If you need further help, please feel free to post, thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.