SEH(Structured Exception Handling)
1) Exception
예외(Exception)란 의도한대로 되지 않았음을 의미한다. 어떤 목적을 위하여 코드를 작성했을 때 그 코드가 정상적으로 의도한대로 작동하지 않은 상황을 예외라고 한다. 여기에는 결과값이 정상적으로 반환되지 않은경우를 포함하여 코드가 오류를 발생시켜 어플리케이션이 종료되는 경우도 포함된다.
이들 예외중에 코드를 작성하면서 짐작할 수 있는 예외(반환값을 처리한다던가 하는..)를 처리해두면 이것은 Handled Exception 이 되는것이고, 짐작하지 못하여 예외를 처리해두지 못한 상황에서 예외가 발생하면 이것은 Unhandled Exception 이라고 한다.
Unhandled Exception 은 개발을 하다보면 흔히 볼 수 있는 ‘응용프로그램 오류’ 같은것이 가장 보기쉬운 예라 할 수 있다. 메모리 할당을 하도록 코드를 작성하고, 실제로 시스템상의 이유로 메모리를 할당하지 못했는데 그 반환값을 체크하지 않고 메모리가 정상적으로 할당되었을 경우만을 고려하여 할당되지 못한 메모리(잘못된 메모리 주소 혹은 NULL 포인터)를 참조하면 Exception(Access Violation 등)이 발생하게 되는것이다.
예)
소스 1)
char *pBuffer;
char szString[] = {“String copy test”};
pBuffer = (char *)malloc(sizeof(char) * (strlen(szString) + 1));
strcpy(pBuffer, szString);
printf(pBuffer);
free(pBuffer);
소스 2)
char *pBuffer = NULL;
char szString[] = {“String copy test”};
pBuffer = (char *)malloc(sizeof(char) * (strlen(szString) + 1));
if(pBuffer != NULL)
{
strcpy(pBuffer, szString);
printf(pBuffer);
free(pBuffer);
}
else printf(“Not enough memory”);
위의 두 소스를 보자. 첫번째 소스는 메모리가 정상적으로 할당되었을 경우만을 고려하여 코드를 작성한것이다. 두번째 소스는 malloc의 반환값을 비교하여 메모리가 정상적으로 할당이 되었을 경우에만 원하는 일을 처리하도록 코딩하였다.
이런 작은 부분을 처리해주는것이 예외 상황이 발생할 수 있는 확률을 줄일 수 있는 가장 쉬운 방법이 되는것이고, 또 예외가 발생하더라도 디버깅을 쉽게할 수 있게 해준다.
실제로 변수의 초기화 와 변수값의 체크, 사용한 함수의 반환값 체크. 이 두가지만 확실히 해주면 대부분의 예외는 미연에 방지할 수 있다. 이미 구현되어있는 함수를 사용하는 경우가 아니라 함수를 작성해야 하는경우에는 반환값에 대해 일정한 룰(예를들면 HRESULT 같은)을 적용하여 구조를 잡아간다면 좀더 쉽게 디버깅이 가능하고, 어떤 문제가 발생할 수 있는지를 그렇지 않은경우보다 훨씬 수월하게 찾아낼 수 있다.
2) try{} catch(...){}
C++ 컴파일러(MSDN에는 C++로 나와있는데 C 컴파일러에서도 지원하는지는 모르겠다.)에서 지원하는 예외처리 방법중에 try, catch 구문이 있다.
try
{
수행할 코드
}
catch(...)
{
예외가 발생했을 경우 수행할 코드
}
간단히 이런 구조로 이루어져있는데, try 블럭에서 예외가 발생하면 catch 블럭으로 수행을 옮겨주는 역할을 한다. 앞의 예제 처럼 한가지 일만해도 된다면 그냥 비교하는 방법으로 처리해도 그다지 복잡해지지 않으니 괜찮을지 모르지만. 처리해야될 일이 많아지고 코드가 길어지게되면 예외를 처리하기 위해 넣어둔 코드가 실제 수행해야할 코드가 더 많아질 수도 있는 일이다.(지나치게 if 구문이 많아지는 경우가 발생할 수 있다.)
예)
BOOL CreateMainWindow(); // 메인 윈도우를 생성하는 함수
BOOL SetInformationToMainWindow(); // 기본정보를 메인윈도우에 세팅
BOOL ShowMainWindow(); // 메인 윈도우를 화면에 보여준다.
이런 함수들로 이루어진 어플리케이션이 있다고 하면...
소스 1)
CreateMainWindow();
SetInformationToMainWindow();
ShowMainWindow();
소스 2)
if(CreateMainWindow())
{
if(SetInformationToMainWindow())
{
if(ShowMainWindow())
{
}
else printf(“Error ? Show main window”);
}
else printf(“Error ? Set information to main window”);
}
else printf(“Error ? Create main window”);
소스 3)
const DWORD ERROR_CREATEMAINWINDOW = 1;
const DWORD ERROR_SETINFOTOMAINWINDOW = 2;
const DWORD ERROR_SHOWMAINWINDOW = 3;
try
{
if(!CreateMainWindow()) throw ERROR_CREATEMAINWINDOW;
if(!SetInformationToMainWindow()) throw ERROR_SETINFOTOMAINWINDOW;
if(!ShowMainWindow()) throw ERROR_SHOWMAINWINDOW;
}
catch (DWORD dwError)
{
printf(“Error code : %d”, dwError);
}
두 소스를 보자. 정상적인 경우 소스 1, 2, 3 모두 동일한 동작을 한다. 하지만 만약 CreateMainWindow() 를 실패했다고 하면 소스 1의 경우 Main Window가 없는데 그 윈도우에 SetInformationToMainWindow()를 수행하려고 한다. 이런경우에 응용프로그램 오류가 발생할 수 있다. 소스 2와 3의 경우는 실패했을경우 오류 메시지를 보이도록 해두었으니 문제는 없다.
이제 소스 2, 3을 보자. 소스 2 의 경우도 소스 3 처럼 오류코드를 받아서 오류 코드가 존재하면 메시지를 보이도록 처리할 수도 있다. 하지만 코드가 소스 3 에 비해 복잡해질 수 있다. 중첩된 if 구문의 사용이 너무 많아질 수 있다.(반드시 그렇지는 않다-_-)
또 다른 생각을 해보자. ShowMainWindow()를 수행한 뒤 또다른 작업을 수행하도록 하라는 지시가 내려왔다(-_-). 저 중첩 if 문 안에 또다른 if 구문을 넣을것인가? 다른 방법을 찾을것인가를 정해야한다. 선택하기 나름이지만 계속 복잡하게 되어가는 소스를 보고있으면 일하기도 싫어진다.
같은 상황을 소스 3 에 적용해보자. 새로 수행할 작업의 함수를 추가하고, 그 함수에 대한 오류코드를 추가하자. 그리고 try 블럭 내부에 그 작업을 수행하도록 하자. 비교는 스스로 해보시길 바란다.
2 - 1) try{} catch(...){}
위에서 얘기하지 않은 것이 있는데, catch(...) 의 정확한 사용법이다. 2) 의 예제 소스에서 보면 catch(DWORD dwError) 로 되어있는데 이것은 throw 로 발생시킨 예외 값이 DWORD 라는 의미이다. 그리고 throw 로 발생한 예외값이 DWORD 값이 아니라면 catch 블럭은 수행되지 않는다. 자기 자신을 필요로하는 예외가 아니라고 생각(-_-)하는 것이다.
그렇다면 예외로 반환될 수 있는 값이 여러가지라면 어떻게 해야하는지 알아보자. 위의 소스 3 을 예로 들어보겠다.
소스 3)
#define ERROR_STCRITICAL 1024
이 #define 은 리소스의 String Table에 있는 “크리티컬 오류발생” 이라는 문자열의 리소스 ID 라고 가정한다.
const DWORD ERROR_CREATEMAINWINDOW = 1;
const DWORD ERROR_SETINFOTOMAINWINDOW = 2;
const DWORD ERROR_SHOWMAINWINDOW = 3;
try
{
if(!CreateMainWindow()) throw ERROR_STCRITICAL;
if(!SetInformationToMainWindow()) throw ERROR_SETINFOTOMAINWINDOW;
if(!ShowMainWindow()) throw ERROR_SHOWMAINWINDOW;
}
catch (DWORD dwError)
{
printf(“Error code : %d”, dwError);
}
위와 같이 소스를 고쳐보았다. 메인윈도우를 생성할 수 없다는 것은 정말 큰일(-_-;;)이기 때문에 메시지를 특별하게! 보여주기로 결정하였다. 하지만 리소스 ID 는 int 값으로 인식을 한다. 이제 ERROR_STCRITICAL 을 처리할 수 있는 catch 블럭을 만들어보자.
위 소스의 catch (DWORD dwError) 블록의 끝부분에 아래코드를 추가해보자.
catch (int nStringID)
{
char szErrorString[1024];
LoadString(AfxGetResourceHandle(), nStringID, szErrorString, 1024);
printf(szErrorString);
}
이렇게 해주시면 되겠다. 그럼 DWORD 값으로 발생한 예외는 catch(DWORD dwError)가 int 값으로 발생한 예외는 catch(int nStringID) 로 처리가 이루어진다.(실제로 DWORD 와 int 가 다르게 작동하는지는 확인해보지 않았다. 이것은 예제이다. 서로 다른 타입의 예외를 처리할 때 어떻게 하는지에 대한 간단한 설명을 위한 예제이다. 실제로는 DWORD와 int를 같이 인식할 수도 있다는 얘기다. 예제 상황임을 확실히 해두자-_-;;;)
3) Unhandled Exception
위의 예제는 모두 Handled Exception에 관한 얘기이다. 예상할 수 있는 일들만 막아냈을 뿐이다. 이제는 우리가 예상하지 못했던 예외의 처리에 대해서 알아보자.
3 ? 1) SetErrorMode
SetErrorMode 라는 함수가 있다. 이 함수가 무슨일을 하느냐 하면.. 다시 얘기하지만 가장 쉽게볼 수 있는 Unhandled Exception 상황, 즉 “응용프로그램 오류가 발생하였습니다.”라는 삭막한 회색창이 있지 않던가? 그 창을 제어해주는 함수이다. 정확히는 제어가 아니라 보여줄까 말까를 설정할 수 있게 해준다.(-_-;) 인자를 살펴보자. 인자를 0 으로 지정하면 삭막한 회색창을 보여준다(디폴트).
SEM_FAILCRITICALERRORS
“응용프로그램 오류”라고 하는 회색창(-_-)을 보여주지 않는다.
SEM_NOGPFAULTERRORBOX
NOGPFAULT 란다. NO General Protection FAULT 를 줄여놓은것이다. 일반 보호오류가 발생해도 회색창을 보여주지 않는다.
SEM_NOOPENFILEERRORBOX
혹시 본적이 있는지 모르겠지만, 파일을 오픈할 때 없는 파일을 오픈하면 오류가 발생한다. 회색이지만(-_-) “응용프로그램 오류” 같은 창이 아닌 메시지 박스가 뜬다(‘빈 파일에 엑세스할 수 없습니다.’라던가? 그 비슷한 메시지를 보여줬던 것 같다). 그걸 안보이게 해준다.
이 함수를 얘기하는 이유는 다음절에 나온다. 3 ? 2 로 넘어가보자.
3 ? 2) SetUnhandledExceptionFilter
자, 드디어 Unhandled Exception 의 본론이다. 이 함수가 무엇을 하는지 우선 알아보면, 위에서 우리가 열심히 막았던 예외를 제외한(다시한번 말하지만 Unhandled Exception 은 예상치 못한 예외(예외가 예상치 못한것이긴 하지만-_-;;;)를 말한다.) 나머지 예외에 대한 처리를 할 수 있도록 도와(!)만 준다. 우선 인자를 살펴보자.
LPTOP_LEVEL_EXCEPTION_FILTER 를 인자로 받는데, 이게 뭘까?
LONG UnhandledExceptionFilter(STRUCT _EXECUTION_POINTERS *ExceptionInfo);
이렇게 정의가 되어있다.
그냥봐도 예외가 발생하면 저 함수를 호출해주는구나 할 수 있을것이다(-_-;). 자 이제 예외를 잡아보자.
아래 예제 소스는 MSJ의 Under the hood에 수록된 예제 소스를 기초로 수정하였습니다. MSJ에 있는 소스는 클래스로 잘 만들어져 있습니다. 간단하게 함수 한 개로 축소했을 뿐입니다.
소스) 우선 핸들러를 정의합니다.
LONG WINAPI UnhandledExceptionFilter(PEXCEPTION_POINTERS pExceptionInfo)
{
PEXCEPTION_RECORD pExceptionRecord = pExceptionInfo->ExceptionRecord;
printf(“Exception code : %08X”, pExceptionRecord->ExceptionCode)
PVOID addr = pExceptionRecord->ExceptionAddress;
TCHAR szModule[MAX_PATH];
DWORD len = sizeof(szModule);
DWORD section = 0;
DWORD offset = 0;
MEMORY_BASIC_INFORMATION mbi;
If(!VirtualQuery(addr, &mbi, sizeof(mbi))) return FALSE;
DWORD hMod = (DWORD)mbi.AllocationBase;
If(!GetModuleFileName((HMODULE)hMod, szModule, len)) return FALSE;
PIMAGE_DOS_HEADER pDosHdr = (PIMAGE_DOS_HEADER)hMod;
PIMAGE_NT_HEADERS pNtHdr = (PIMAGE_NT_HEADERS)(hMod + pDosHdr->e_lfanew);
PIMAGE_SECTION_HEADER pSection = IMAGE_FIRST_SECTION(pNtHdr);
DWORD rva = (DWORD)addr ? hMod;
for(unsigned int i = 0; i < pNtHdr->FileHeader.NumberOfSections; i++, pSection++)
{
DWORD sectionStart = pSection->VirtualAddress;
DWORD sectionEnd = sectionStart + max(pSection->SizeOfRawData, pSection->Misc.VirtualSize);
If((rva >= sectionStart) && (rva <= sectionEnd))
{
section = i + 1;
offset = rva ? sectionStart;
break;
}
}
printf(“Fault Address : %08X %02X:%08X %s”, pExceptionRecord->ExceptionAddress, section, offset, szModule);
}
핸들러를 설치해야겠죠.
LPTOP_LEVEL_EXCEPTION_FILTER lpPreviousFilter = NULL;
lpPreviousFilter = SetUnhandledExceptionFilter(UnhandledExceptionFilter);
종료될때는 이전 핸들러를 복구해주면 끝입니다.
SetUnhandledExceptionFilter(lpPreviousFilter);
이정도가 기본코드라고 할 수 있겠군요. 이제 예외가 발생하면 UnhandledExceptionFilter 를 호출해줄 것입니다. 예외가 발생하면 아래와같이 출력될 것입니다.
Exception code: C0000005
Fault address: 0183B877 01:0000A877 C:\XXXXXXXX.dll
C0000005 는 예외 코드입니다. 예외 코드 값은 아래와 같이 정의되어 있습니다.
#define EXCEPTION_ACCESS_VIOLATION STATUS_ACCESS_VIOLATION
#define EXCEPTION_DATATYPE_MISALIGNMENT STATUS_DATATYPE_MISALIGNMENT
#define EXCEPTION_BREAKPOINT STATUS_BREAKPOINT
#define EXCEPTION_SINGLE_STEP STATUS_SINGLE_STEP
#define EXCEPTION_ARRAY_BOUNDS_EXCEEDED STATUS_ARRAY_BOUNDS_EXCEEDED
#define EXCEPTION_FLT_DENORMAL_OPERAND STATUS_FLOAT_DENORMAL_OPERAND
#define EXCEPTION_FLT_DIVIDE_BY_ZERO STATUS_FLOAT_DIVIDE_BY_ZERO
#define EXCEPTION_FLT_INEXACT_RESULT STATUS_FLOAT_INEXACT_RESULT
#define EXCEPTION_FLT_INVALID_OPERATION STATUS_FLOAT_INVALID_OPERATION
#define EXCEPTION_FLT_OVERFLOW STATUS_FLOAT_OVERFLOW
#define EXCEPTION_FLT_STACK_CHECK STATUS_FLOAT_STACK_CHECK
#define EXCEPTION_FLT_UNDERFLOW STATUS_FLOAT_UNDERFLOW
#define EXCEPTION_INT_DIVIDE_BY_ZERO STATUS_INTEGER_DIVIDE_BY_ZERO
#define EXCEPTION_INT_OVERFLOW STATUS_INTEGER_OVERFLOW
#define EXCEPTION_PRIV_INSTRUCTION STATUS_PRIVILEGED_INSTRUCTION
#define EXCEPTION_IN_PAGE_ERROR STATUS_IN_PAGE_ERROR
#define EXCEPTION_ILLEGAL_INSTRUCTION STATUS_ILLEGAL_INSTRUCTION
#define EXCEPTION_NONCONTINUABLE_EXCEPTION STATUS_NONCONTINUABLE_EXCEPTION
#define EXCEPTION_STACK_OVERFLOW STATUS_STACK_OVERFLOW
#define EXCEPTION_INVALID_DISPOSITION STATUS_INVALID_DISPOSITION
#define EXCEPTION_GUARD_PAGE STATUS_GUARD_PAGE_VIOLATION
#define EXCEPTION_INVALID_HANDLE STATUS_INVALID_HANDLE
이제 실제로 오류가 발생한곳을 찾아봐야겠군요.
Fault address: 0183B877 01:0000A877 C:\XXXXXXXX.dll
0183B877 은 예외가 발생한 주소입니다.
0001:0000A877 은 예외가 발생한곳의 논리주소(Logical Address)입니다. 이 주소를 찾아가면 어디서 오류가 발생했는지를 알 수있습니다.
이 주소를 추적하기 위해서는 MAP이 필요합니다. 여러가지 정보를 많이 만들어주는데 그중에서 논리주소만 참조하면 되었던 것 같습니다. MAP 파일은 Project Settings -> Link -> Generate mapfile 을 체크하시면 Debug 혹은 Release 디렉토리에 *.map 파일이 만들어집니다. 그럼 *.map 파일을 열어보면...
XXXXXXXX
Timestamp is 3e1e58ab (Fri Jan 10 14:22:51 2003)
Preferred load address is 10000000
Start Length Name Class
0001:00000000 00017553H .text CODE
0001:00017553 00000bf0H .text$AFX_AUX CODE
0001:00018143 00000093H .text$AFX_COL1 CODE
0001:000181d6 000002abH .text$AFX_COL2 CODE
0001:00018481 00005db2H .text$AFX_CORE1 CODE
0001:0001e233 000008e7H .text$AFX_CORE2 CODE
0001:0001eb1a 0000051cH .text$AFX_CORE3 CODE
0001:0001f036 00000082H .text$AFX_CORE4 CODE
0001:0001f0b8 00001989H .text$AFX_INIT CODE
0001:00020a41 00000000H .text$AFX_OLE1 CODE
-------------------- 생략 ----------------------------------
Address Publics by Value Rva+Base Lib:Object
0001:00000000 ??0CFileEx@@QAE@XZ 10001000 f FileEx.obj
0001:00000016 ??_GCFileEx@@UAEPAXI@Z 10001016 f i FileEx.obj
0001:00000016 ??_ECFileEx@@UAEPAXI@Z 10001016 f i FileEx.obj
0001:00000032 ??1CFileEx@@UAE@XZ 10001032 f FileEx.obj
0001:00000076 ?ReadLine@CFileEx@@QAEKPAPAXK@Z 10001076 f FileEx.obj
-------------------- 생략 ----------------------------------
이런식의 알것도 같고 모를것도 같은 이상한것들이 마구 저장되어 있는 것을 볼 수 있습니다.
Fault address: 0183B877 01:0000A877 C:\XXXXXXXX.dll
이렇게 되어있으니까...0001:0000A877 에 가장 가까운곳을 Address에서 찾아봅니다. 쭉 찾아보니.. 이렇게 나오는군요..
0001:0000a719 ?OnClicked1@CXXXXXXXXDlg@@IAEJGGPAUHWND__@@AAH@Z 1000b719 f XXXXXXXX.obj
0001:0000a7e6 ?ControlEvent@CXXXXXXXXDlg@@IAEXXZ 1000b7e6 f XXXXXXXX.obj
0001:0000a947 ?GetTest@CXXXXXXXXDlg@@QAEKXZ 1000b947 f XXXXXXXX.obj
굵은글씨로 되어있는곳과 그 다음라인의 사이에 오류가 발생한 주소가 있습니다. 즉 굵은글씨로 되어있는 함수 내부에서 오류가 발생하였다는 것입니다. 이제 그 함수를 살펴보면 됩니다. 정확하게 집어내지는 못하더라도 어느 함수가 오류를 발생시켰는지는 알아낼 수 있습니다. 물론 디버그모드 릴리즈모드 공히 적용할 수 있습니다.
3 ? 3) Callstack
디버그를 하다보면 Callstack을 자주 이용하게 됩니다. 디버깅 하는데 아주 유용하죠. Unhandled Exception을 처리하는데도 오류가 발생한 곳의 Callstack을 볼 수 있다면 정말 좋을 것 같지 않으십니까?
소스)
BOOL GetLogicalAddress(PVOID addr, PTSTR szModule, DWORD len, DWORD §ion, DWORD &offset)
{
MEMORY_BASIC_INFORMATION mbi;
if(!VirtualQuery(addr, &mbi, sizeof(mbi))) return FALSE;
DWORD hMod = (DWORD)mbi.AllocationBase;
if(!GetModuleFileName((HMODULE)hMod, szModule, len)) return FALSE;
PIMAGE_DOS_HEADER pDosHdr = (PIMAGE_DOS_HEADER)hMod;
PIMAGE_NT_HEADERS pNtHdr = (PIMAGE_NT_HEADERS)(hMod + pDosHdr->e_lfanew);
PIMAGE_SECTION_HEADER pSection = IMAGE_FIRST_SECTION(pNtHdr);
DWORD rva = (DWORD)addr - hMod; // RVA is offset from module load address
for(unsigned i = 0; i < pNtHdr->FileHeader.NumberOfSections; i++, pSection++)
{
DWORD sectionStart = pSection->VirtualAddress;
DWORD sectionEnd = sectionStart + max(pSection->SizeOfRawData, pSection->Misc.VirtualSize);
if((rva >= sectionStart) && (rva <= sectionEnd))
{
section = i + 1;
offset = rva - sectionStart;
return TRUE;
}
}
return FALSE;
}
UnhandledExceptionFilter 함수의 맨 아래쪽에 코드를 추가합니다.
PCONTEXT pCtx = pExceptionInfo->ContextRecord;
DWORD pc = pCtx->Eip;
PDWORD pFrame, pPrevFrame;
pFrame = (PDWORD)pCtx->Ebp;
do
{
TCHAR szModule[MAX_PATH] = _T(““);
DWORD section = 0, offset = 0;
GetLogicalAddress((PVOID)pc, szModule, sizeof(szModule), section, offset);
printf(“%08X %08X %04X:%08X %s”, pc, pFrame, section, offset, szModule);
pc = pFrame[1];
pPrevFrame = pFrame;
pFrame = (PDWORD)pFrame[0];
if((DWORD)pFrame & 3) break;
if(pFrame <= pPrevFrame) break;
if(IsBadWritePtr(pFrame, sizeof(PVOID) * 2)) break;
} while(TRUE);
휴.. 힘들군요 이거.. 이 소스도 MSJ에 수록된 IntelStackWalk 라는 함수의 소스입니다. 함수 이름에서 아실 수 있으시겠지만 x86 계열의 CPU에서만 동작합니다. 이 부분의 출력 결과는 대강 아래와 같습니다.
0183B877 0012F9D4 0001:0000A877 E:\XXXXXXX.dll
XXXXXXXX XXXXXXXX 0001:XXXXXXXX E:\XXXXXXX.dll
맨 윗줄이 예외를 발생시킨 위치이고, 아래로는 그 부분을 호출한 콜스택이 쭈욱 나열됩니다.
4) ...
몇가지 예외 처리에 대한 방법을 알아보았습니다. SetErrorMode 라는 함수를 설명한 것은 3 에서 설명한 Unhandled Exception Handler에서 “응용프로그램 오류”같은 회색상자가 아니라 IE 혹은 MSN 이 오류를 발생시켰을 때 보여주는 것 처럼 좀더 나은 인터페이스의 오류 화면을 보여줄 수 있기 때문입니다. 옵션을 끄지 않으면 그 회색상자(-_-;;;)가 보이면서 같이 보이기 때문에 그다지 좋지는 않아보이더군요. 좀더 자세한 내용은 아래 링크를 참조 하시면됩니다.
http://www.microsoft.com/msj/defaultframe.asp?page=/msj/0497/hood/hood0497.htm
http://www.microsoft.com/msj/defaultframe.asp?page=/msj/0597/hood0597.htm
MSDN - Exception Handling
MSDN - Exceptions: Using MFC Macros and C++ Exceptions
MSDN - Exception Handling Topics (SEH)
