Fog Creek Software
Discussion Board




Betting your company on .NET

Microsoft can do it, so why can't I?

So, halfway down our very first .NET project, I bump in to these strange errors (bugs?):

- Errors thrown in a try block in a WindowsForms application don't get caught! At least not by the catch clause: Instead, a Message shows up, allowing you to ignore the error (bypassing the catch) or close the application...

- MessageBox.Show() in the Click-Event of a CommandButton on a Form displayed with ShowDialog() closes the Form! The rest of the Click-Event-Code gets run, though, but after that? Next statement is the one after ShowDialog().

Does anyone know what to do? I will try to PInvoke around MessageBox.Show() - that might help, but really... That's not what I was expecting from .NET!

I did try to run the App on a PC without the IDE (like what the customer will be using) and the same problems persist!

What do I tell the customer now? Uh... we need to rewrite? Uh... we need to wait for the next service pack?

Daren Thomas
Tuesday, June 08, 2004

You're not going to want to hear this, but things aren't going exactly as you think they're going. If the exception were really being thrown inside your try block, it would be caught. So something else is happening.

Good luck tracking it down.

Brad Wilson (dotnetguy.techieswithcats.com)
Tuesday, June 08, 2004

I keep telling you guys - no email, no help. :-/

Philo

Philo
Tuesday, June 08, 2004

Dear Philo,

alas, not all of us guys read all of your posts. But if you really do want to help, I have included my email.

Daren Thomas
Tuesday, June 08, 2004

OK.

"- Errors thrown in a try block in a WindowsForms application don't get caught! At least not by the catch clause: Instead, a Message shows up, allowing you to ignore the error (bypassing the catch) or close the application..."

Yes I get this too if I code:

try
  application.run
catch ex as exception
  msgbox "An error"
end try

It works ok in debug but when you run it standalone I get the box you talk about. I know now why. If you find the answer to this then please tell me!!!!

"- MessageBox.Show() in the Click-Event of a CommandButton on a Form displayed with ShowDialog() closes the Form! The rest of the Click-Event-Code gets run, though, but after that? Next statement is the one after ShowDialog()."

Check that the DialogResult property of the button is set to "None". If it's set to anything else then the ShowDialog function will exit with that value once it has executed the Click-Event-Code

gwyn
Tuesday, June 08, 2004

"I know NOT why"

gwyn
Tuesday, June 08, 2004

gwyn, thanx! That DialogResult property did the trick. PUSH that onto the stack of things to think of, when I next design a dialog :)

I found a kb artikle about the error message:

http://support.microsoft.com/?kbid=836674

will reply when I have read it.

Daren Thomas
Tuesday, June 08, 2004

Rats, the kb article in above post doesn't help at all. I'm also not sure if I understand the text in the "cause" section. I strongly suspect the person who wrote it didn't either...

Daren Thomas
Tuesday, June 08, 2004

Well reading through the KB article the cause is that there are two different methods used to handle the exception depending on whether you are running in debug or not.

If you are running in debug the method used uses the JIT debugger to populate the error message of the exception handler.  If you are not running in debug, then the method used throws up an error dialog and uses that to populate the error message.

Looks like one of those things that seemed like a good idea at the time, as opposed to an out right bug.

So the recommended work around didn't help?

Steve Barbour
Tuesday, June 08, 2004

No, the workaround didn't work. Has anybody ever had this work?

Daren Thomas
Tuesday, June 08, 2004

" Errors thrown in a try block in a WindowsForms application don't get caught! At least not by the catch clause: Instead, a Message shows up, allowing you to ignore the error (bypassing the catch) or close the application..."

One thing to consider is that if the code inside your try/catch block create a new thread then any exception raised in the new thread will not be caught by your try/catch block.

"I'm not using multithreading" you may say, but not so fast! If you are making calls to COM components then there is a good chance that these components are being executed in a different thread. Furthermore, much of the .NET Framework is just a wrapper around COM. So even if you aren't calling your own custom COM objects, you might still be making calls to COM.

Mark Hoffman
Tuesday, June 08, 2004

Richter's book documents a few cases where the FCL writers didn't follow their own guidelines, like an exception on CurrentCell of the DataGrid catches all exceptions and opens a message box!

One I know of is that XmlDocument.Load documents an XMLException, but will also throw undocumented IOExceptions (perhaps obvious, but it should be documented).

el
Tuesday, June 08, 2004

BTW: I finally got the workaround to work. So we have a solution to the try/catch-BUG...

Daren Thomas
Tuesday, June 08, 2004

Have fun getting impersonation to work correctly. 

Sassy
Tuesday, June 08, 2004


"Have fun getting impersonation to work correctly.  "

What problems did have you, Sassy? I've got a snippet of the code that I've used for years that handles impersonation to and from a user.

Mark Hoffman
Tuesday, June 08, 2004

Problem I'm having is running a CLI application from an ASP.NET form, doing an XCOPY to a remote drive

Issue seems to be that the CLI executable won't inherit the impersonated user. 

I'm running ASP.NET as System in machine.config, it makes zero sense to me that this isn't working.

I even tracked down a c# class to handle impersonation using LogonUser from the windows API.

No dice.

Sassy
Tuesday, June 08, 2004

What you see is the default ThreadException handler for a Windows Forms application. So you want to define your own ThreadException handler.

Inside Main, first write this:

Application.ThreadException += new ThreadExceptionHandler(OnThreadException);

...before typing Application.Run(form).

Then define your private static handler OnThreadException somewhere else in the form's class.

Chris Nahr
Tuesday, June 08, 2004

Er, that refers to the original post and Windows Forms... don't know where else this thread meandered.

Chris Nahr
Tuesday, June 08, 2004

Sassy, impersonation only gets you access to resources on the local machine.  To access a remote machine, you'll also need to use delegation.

Check out: http://msdn.microsoft.com/library/en-us/vsent7/html/vxconASPNETDelegation.asp

Joe
Tuesday, June 08, 2004

Actually in this case I'm just exceuting a program on the local machine that needs to access a remote file share.  The solution was to dump the .NET System.Diagnostics.Process class in favor of another available here:
http://weblogs.asp.net/kennykerr/

This class contains the ability to  run some code as another user, so .NET impersonation is not necessary at all.

Sassy
Tuesday, June 08, 2004

>>What do I tell the customer now? Uh... we need to
>>rewrite? Uh... we need to wait for the next service
>>pack?

No - tell them to get another software developer - or learn how to use a debugger.

clueful
Tuesday, June 08, 2004

Executing a program on the local machine with impersonated security credentials which will access resources on another machine is the definition of delegation :) 

Even if you spawn another process with your impersonated credentials, the new process still gets marked as "impersonated" and therefore defaults back to its original credentials when it attempts to access network resources.  The exception to this is domain accounts (normally user, but also machine accounts for processes running as Network Service) which are specifically granted the right to "delegate" (ie, talk across the network), using the setspn.exe utility.

Impersonation/Delegation isn't for the faint of heart, but it *does* work :)  There are a *lot* of security issues surrounding delegation, which is why it's so complicated, but if you put on your sysadmin cap and do a little research, it's certainly doable, and a very useful tool.  Yes, you can solve some of the same problems using a Windows Service to avoid impersonation, but that requires more code, too, and may not always be feasible...

Anyway, glad you found another solution that works for you =)

Joe
Tuesday, June 08, 2004

"Microsoft can do it, so why can't I?"

I think Joel has stated several times that this is a foolish attitude to have.  Microsoft makes their own gravity.  They can do things you can't.

(Whether betting on .NET is something you can get away with is left as an exercise to the reader.)

Wally
Tuesday, June 08, 2004

Sassy,
Here is one of articles you may want to check about it (search on Google for "ntlm kerberos ASP.Net") http://msdn.microsoft.com/library/en-us/vsent7/html/vxconaspnetdelegation.asp

WildTiger
Tuesday, June 08, 2004

*  Recent Topics

*  Fog Creek Home