Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 5개 있습니다.)
(시리즈 글이 11개 있습니다.)
디버깅 기술: 6. .NET 예외 처리 정리
; https://www.sysnet.pe.kr/2/0/316

디버깅 기술: 15. First-Chance Exception
; https://www.sysnet.pe.kr/2/0/510

디버깅 기술: 16. Watson Bucket 정보를 이용한 CLR 응용 프로그램 예외 분석
; https://www.sysnet.pe.kr/2/0/595

.NET Framework: 110. WPF - 전역 예외 처리
; https://www.sysnet.pe.kr/2/0/614

디버깅 기술: 42. Watson Bucket 정보를 이용한 CLR 응용 프로그램 예외 분석 - (2)
; https://www.sysnet.pe.kr/2/0/1096

.NET Framework: 534. ASP.NET 응용 프로그램이 예외로 프로세스가 종료된다면?
; https://www.sysnet.pe.kr/2/0/10863

.NET Framework: 538. Thread.Abort로 인해 프로세스가 종료되는 현상
; https://www.sysnet.pe.kr/2/0/10867

디버깅 기술: 110. 비동기 코드 실행 중 예외로 인한 ASP.NET 프로세스 비정상 종료 현상
; https://www.sysnet.pe.kr/2/0/11383

디버깅 기술: 119. windbg 분석 사례 - 종료자(Finalizer)에서 예외가 발생한 경우 비정상 종료(Crash) 발생
; https://www.sysnet.pe.kr/2/0/11732

닷넷: 2148. C# - async 유무에 따른 awaitable 메서드의 병렬 및 예외 처리
; https://www.sysnet.pe.kr/2/0/13422

닷넷: 2213. ASP.NET/Core 웹 응용 프로그램 - 2차 스레드의 예외로 인한 비정상 종료
; https://www.sysnet.pe.kr/2/0/13551




ASP.NET 응용 프로그램이 예외로 프로세스가 종료된다면?

우연히 검색하다가 다음과 같은 질문이 있는 것을 보게 되었습니다.

How to treat unhandled thread-exceptions in ASP.NET?
; http://stackoverflow.com/questions/11117167/how-to-treat-unhandled-thread-exceptions-in-asp-net

질문인 즉, 다음의 코드와 같이 ASP.NET 요청을 처리하는 스레드가 아닌, 2차적으로 생성한 스레드에서 예외가 발생하면,

protected void Page_Load(object sender, EventArgs e)
{
    var thread = new Thread(() =>
        {
            throw new InvalidOperationException("some failure on a helper thread");
        });
    thread.Start();
    thread.Join();
}

w3wp.exe 프로세스가 비정상 종료된다는 것입니다. 이와 비슷한 질문이 또 하나 있습니다.

Handling unhandled Task exceptions in ASP.NET 4
; https://evolpin.wordpress.com/2013/05/26/handling-unhandled-task-exceptions-in-asp-net-4/

위의 글에서도 ASP.NET 요청 스레드가 아닌, Task 타입을 이용한 2차 스레드 내부에서 작업을 하는 도중 예외가 발생하면 프로세스가 종료된다는 것입니다.

protected void Button_Click(object sender, EventArgs e)
{
    Task.Factory.StartNew(() =>
    {
        Task.Factory.StartNew(() =>
        {
            Task.Factory.StartNew(() =>
            {
                throw new ApplicationException("deepest exception");
            }, TaskCreationOptions.AttachedToParent);
 
            throw new ApplicationException("internal exception");
        }, TaskCreationOptions.AttachedToParent);
 
        System.Threading.Thread.Sleep(100);
        throw new ApplicationException("exception");
    }, TaskCreationOptions.LongRunning);
}

글에서도 나오지만, .NET 4.0에 이런 현상이 있었고 마이크로소프트는 .NET 4.5부터 Task 내에서 자동으로 예외 처리를 하는 것으로 바꿔 프로세스 종료가 안되도록 했다고 합니다. 대신 .NET 4.0처럼 프로세스가 종료되는 식의 동작을 하고 싶다면 web.config에 ThrowUnobservedTaskExceptions 옵션을 적용해 제어할 수 있게 했습니다.

결국, 이 문제의 원인도 같습니다. 2차 스레드에서 예외가 발생하면 프로세스가 죽는 현상이 발생한 것이고 위의 글에서는 .NET 4.0에서의 문제를 해결하기 위해 HTTP 모듈까지 작성하는 해결책을 보여주고 있습니다.




이미 아시는 분들도 계시겠지만, 사실 이 문제는 약간 .NET의 역사적인 면을 알아야 합니다.

처음 .NET 1.x 시절에는 2차 스레드에서 예외가 발생한 경우 마이크로소프트는 그것을 조용히 스레드만 종료하는 식으로 처리를 했습니다. 하지만, .NET 2.0부터 그 동작을 스레드를 조용히 종료하는 식이 아닌, 프로세스를 종료하는 식으로 바꿨습니다. 아마도 이 결정에 대해서는 호불호가 갈릴 것입니다.

단지, 제 의견은 2.0에서의 동작을 찬성합니다. 왜냐하면, 2차 스레드가 조용히 죽어버리면 대부분의 개발자들이 자신의 코드에 어떤 문제가 발생하고 있는지 모르기 때문입니다. 따라서, 프로그램의 '안정성'을 향상시킬 수 있는 여지가 없어져 버립니다.

물론, 마이크로소프트는 개발자들이 .NET 1.x에서처럼 동작하기를 바랄 수 있으므로 .NET 2.0에서도 그렇게 동작시킬 수 있는 옵션을 두었습니다. 이 설정은 aspnet.config 파일에 할 수 있는데 자신의 닷넷 응용 프로그램 유형에 따라 각각 다음의 설정 파일에 대해,

.NET 2.0 32비트: %WINDIR%\Microsoft.NET\Framework\v2.0.50727\aspnet.config
.NET 4.0 32비트: %WINDIR%\Microsoft.NET\Framework\v4.0.30319\aspnet.config

.NET 2.0 64비트: %WINDIR%\Microsoft.NET\Framework64\v2.0.50727\aspnet.config
.NET 4.0 64비트: %WINDIR%\Microsoft.NET\Framework64\v4.0.30319\aspnet.config

legacyUnhandledExceptionPolicy 값을 true로 설정하면 됩니다.

<?xml version="1.0" encoding="UTF-8" ?>
<configuration>
    <runtime>
        <legacyUnhandledExceptionPolicy enabled="true" />
        ...생략]...
    </runtime>
</configuration>

애석한 점은, 왜 하필 마이크로소프트가 이 옵션을 aspnet.config에 두었냐는 것입니다. 이로 인해 legacyUnhandledExceptionPolicy 옵션을 web.config 내에서 재정의할 수 없기 때문입니다. 어쩔 수 없이, 개발자들은 해당 시스템에 로그인한 후 관리자 권한의 메모장을 열어 (일관성을 위해) 4개의 파일을 각각 변경해야 하는 수고로움이 있는 것입니다.

아마도 web.config에서만 재정의할 수 있게 했어도 많은 불편함이 사라질 수 있었을 텐데... ^^;

참고로, 예전에도 legacyUnhandledExceptionPolicy 옵션을 설명한 적이 있었습니다.

.NET 예외 처리 정리
; https://www.sysnet.pe.kr/2/0/316




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 9/16/2021]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




... 31  32  33  34  35  36  37  38  39  40  41  42  43  [44]  45  ...
NoWriterDateCnt.TitleFile(s)
12548정성태3/4/20218691개발 환경 구성: 546. github workflow/actions에서 nuget 패키지 등록하는 방법
12547정성태3/3/20219112오류 유형: 699. 비주얼 스튜디오 - The 'CascadePackage' package did not load correctly.
12546정성태3/3/20218767개발 환경 구성: 545. github workflow/actions에서 빌드시 snk 파일 다루는 방법 - Encrypted secrets
12545정성태3/2/202111523.NET Framework: 1026. 닷넷 5에 추가된 POH (Pinned Object Heap) [10]
12544정성태2/26/202111736.NET Framework: 1025. C# - Control의 Invalidate, Update, Refresh 차이점 [2]
12543정성태2/26/202110056VS.NET IDE: 158. C# - 디자인 타임(design-time)과 런타임(runtime)의 코드 실행 구분
12542정성태2/20/202112391개발 환경 구성: 544. github repo의 Release 활성화 및 Actions를 이용한 자동화 방법 [1]
12541정성태2/18/20219623개발 환경 구성: 543. 애저듣보잡 - Github Workflow/Actions 소개
12540정성태2/17/20219934.NET Framework: 1024. C# - Win32 API에 대한 P/Invoke를 대신하는 Microsoft.Windows.CsWin32 패키지
12539정성태2/16/20219868Windows: 189. WM_TIMER의 동작 방식 개요파일 다운로드1
12538정성태2/15/202110291.NET Framework: 1023. C# - GC 힙이 아닌 Native 힙에 인스턴스 생성 - 0SuperComicLib.LowLevel 라이브러리 소개 [2]
12537정성태2/11/202111328.NET Framework: 1022. UI 요소의 접근은 반드시 그 UI를 만든 스레드에서! - 두 번째 이야기 [2]
12536정성태2/9/202110277개발 환경 구성: 542. BDP(Bandwidth-delay product)와 TCP Receive Window
12535정성태2/9/20219440개발 환경 구성: 541. Wireshark로 확인하는 LSO(Large Send Offload), RSC(Receive Segment Coalescing) 옵션
12534정성태2/8/20219923개발 환경 구성: 540. Wireshark + C/C++로 확인하는 TCP 연결에서의 closesocket 동작 [1]파일 다운로드1
12533정성태2/8/20219633개발 환경 구성: 539. Wireshark + C/C++로 확인하는 TCP 연결에서의 shutdown 동작파일 다운로드1
12532정성태2/6/202110125개발 환경 구성: 538. Wireshark + C#으로 확인하는 ReceiveBufferSize(SO_RCVBUF), SendBufferSize(SO_SNDBUF) [3]
12531정성태2/5/20219130개발 환경 구성: 537. Wireshark + C#으로 확인하는 PSH flag와 Nagle 알고리듬파일 다운로드1
12530정성태2/4/202113365개발 환경 구성: 536. Wireshark + C#으로 확인하는 TCP 통신의 Receive Window
12529정성태2/4/202110350개발 환경 구성: 535. Wireshark + C#으로 확인하는 TCP 통신의 MIN RTO [1]
12528정성태2/1/20219751개발 환경 구성: 534. Wireshark + C#으로 확인하는 TCP 통신의 MSS(Maximum Segment Size) - 윈도우 환경
12527정성태2/1/20219923개발 환경 구성: 533. Wireshark + C#으로 확인하는 TCP 통신의 MSS(Maximum Segment Size) - 리눅스 환경파일 다운로드1
12526정성태2/1/20217759개발 환경 구성: 532. Azure Devops의 파이프라인 빌드 시 snk 파일 다루는 방법 - Secure file
12525정성태2/1/20217488개발 환경 구성: 531. Azure Devops - 파이프라인 실행 시 빌드 이벤트를 생략하는 방법
12524정성태1/31/20218631개발 환경 구성: 530. 기존 github 프로젝트를 Azure Devops의 빌드 Pipeline에 연결하는 방법 [1]
12523정성태1/31/20218679개발 환경 구성: 529. 기존 github 프로젝트를 Azure Devops의 Board에 연결하는 방법
... 31  32  33  34  35  36  37  38  39  40  41  42  43  [44]  45  ...