5

Possible Duplicate:
Avoiding first chance exception messages when the exception is safely handled

At the moment I am working on a WPF program which has to interact with DLLs programmed with C++. However, during some debugging I saw in the Debug-Output window the message *“First-chance exception at 0x7637c41f in ***.exe: 0x0000071A: The remote procedure call was cancelled.”* just after I closed the program.

Because I was unable to eliminate this exception, I started fresh with a brand new WPF project and enabled “unmanaged code debugging” and there it was the same exception without any other changes of the settings and even without any changes of the generated source code.

Now I wonder if other people experienced the same issue and how I can resolve it.

[EDIT]

To reproduce this issue I only need to

  1. create a new WPF Application
  2. in WpfApplication1 Properties → Debug → Enable unmanaged code debugging
  3. Start Debugging
  4. Close MainWindow
  5. Look at Debug-Output (Debug → Windows → Output)
Community
  • 1
  • 1
user667967
  • 628
  • 1
  • 8
  • 20
  • Please show a code which allows to reproduce this issue – sll Oct 29 '12 at 11:36
  • Thanks for your interest. As I tried to explain, I did not change any of the automatically generated source code. To reproduce this issue I only need to enable “unmanaged code debugging” and look at the Debug-Output window after executing the unmodified WPF program. – user667967 Oct 29 '12 at 11:47
  • What are those "DLLs programmed with C++" doing? How do you conclude that there is a "Bug in WPF"? It's very much more likely that it's a bug in your DLLs. And "code to reproduce the issue" means reproduce *for us* of course. – Clemens Oct 29 '12 at 11:53
  • To reproduce this issue I only need to (1) create a new WPF Application (2) in WpfApplication1 Properties -> Debug -> Enable unmanaged code debugging (3) Start Debugging (4) Close MainWindow (5) Look at Debug-Output (Debug -> Windows -> Output) – user667967 Oct 29 '12 at 12:03
  • Ok, i can reproduce it. Found [this](http://social.msdn.microsoft.com/forums/en-US/wpf/thread/e4fe4196-5606-49ff-9a82-25ba3df274cd). Please note the answer given by Brendan Clark. – Clemens Oct 29 '12 at 12:59
  • 4
    Wow, "closed as exact duplicate"? This is nowhere near the same question as the "possible duplicate". This question was about a particular exception observed when using WPF. Exceptions thrown during the course of normal operations - even first-chance exceptions - should always be viewed with suspicion and are indicative of possible problems. The OP was right to seek an explanation. – tgr42 Dec 19 '12 at 14:50
  • 1
    I've seen the exact issue too. Plus one other first chance. I tried the exact minimal test case too. I've ignored it for years, but still, it's unsettling. I find WPF unsettling in many ways and always recommend Winforms or MFC. WPF features are not worth the risk for mission critical apps and maintenance and complexity takes it to an even riskier risk. – Robert Jul 15 '16 at 23:36
  • This question should be re-opened because it specifically deals with the particular exception that is thrown by WPF during the closing of a WPF window. The so-called "duplicate" question deals more generally with ***any*** first-chance exception. – Glenn Slayden Jun 27 '19 at 17:41
  • @GlennSlayden - this is a really old question and the OP hasn't returned in over a year. Do you have a specific answer you want to add? – dbc Jun 27 '19 at 21:27
  • @dbc I thought I did, but my clever suggestion ended up not working out. Ok to keep this closed, I guess, although it does still seem unrelated to the linked dup. – Glenn Slayden Jun 27 '19 at 21:44

1 Answers1

0

If you get a “first chance exception”, but not “unhandled exception”, that means an exception was thrown and then caught by some piece of code. So it's not actually a bug, it's most likely working as intended and you don't have to worry about it.

svick
  • 236,525
  • 50
  • 385
  • 514