Ciche awarie w C#, pozornie nieobsłużone wyjątki, które nie psuje programowi

Question

w app WinForm, w przypadku załadować formularza, dodaj następującą linię:

throw new Exception(); 

i uruchomić aplikację. Działał bez problemu. Nazywa się to cichą awarią, możesz próbować dodawać skrzynki wiadomości przed i po, a wkrótce przekonasz się, że zamiast awarii aplikacji, instrukcja throw właśnie wychodzi ze zdarzenia Load.

Jestem pewien, że nie ma potrzeby wyjaśniania, jak brzydkie i niebezpieczne jest to.

Zastanawiam się jednak nad przyczynami (prawdopodobnie z historii) tego przerażającego zachowania. Jestem pewien, że to nie jest decyzja projektowa, prawdopodobnie brak wyboru lub lenistwo. Czy ktoś wie?

Byłoby miło, gdyby ktoś mógł wskazać mi listę zdarzeń, które mogą powodować również poważne awarie.

Oto fragment mojego kodu - nie mam pojęcia jak to może pomóc - ale tutaj jest:

using System; 
using System.Collections.Generic; 
using System.Linq; 
using System.Windows.Forms; 

namespace WindowsFormsApplication1 
{ 
    static class Program 
    { 
     /// <summary> 
     /// The main entry point for the application. 
     /// </summary> 
     [STAThread] 
     static void Main() 
     { 
      Form f = new Form(); 
      f.Load += new EventHandler((x, y) => { throw new Exception(); }); 
      Application.Run(f); 
     } 

    } 
} 

EDIT Wydaje się to nie wydarzyło każdemu. Używam: fw 3.5, winforms, vs 2008, vista x64, nowy czysty projekt WinForm, z kodem wspomnianym powyżej.

Answer 1

To known problem on x64 systems:

Jest to znany problem w 64-bitowym systemie operacyjnym platformy. Powodem jest to, że 64-bitowy rdzeń systemu operacyjnego nie pozwala na wyjątek trybu użytkownika w trybie stosu kernala. Wyjątek jest połknięty przez OS sliently. Tak dzieje się w procedurze obsługi FormLoad , ponieważ wywoływana jest ona w wywołaniu zwrotnym OS . 32-bitowy system operacyjny tego nie robi, , więc nie ma tam repro.

Zespół systemu operacyjnego bada powiązane problemy z numerami . W międzyczasie masz , aby obejść ten problem. Włączenie "Zatrzymaj przy pierwszej szansie wyjątku" spowoduje, że debugger zatrzyma się w tym scenariuszu . Ale to sprawia, że ​​debugger przestaje być bardzo często, więc możesz może to zrobić tylko wtedy, gdy znajdziesz problem.

Połączony raport o błędzie został ostatnio zaktualizowany w lutym 2008 r. I nie wskazuje, co się stało od tego czasu.

Mogę odtworzyć zachowanie większości plakatów w moim 32-bitowym systemie tutaj i mogę odtworzyć zachowanie OP na moim 64-bitowym (Vista SP2, 3.5SP1 Framework) komputerze roboczym.