http://blog.naver.com/techshare/100172047271
위에서 퍼온글입니다.
얼마 전 고객사에서 희한한 버그가 발생했습니다. Visual Basic .NET으로 만들어진 어셈블리였는데, 구현된 클래스 중에서 별로 특징적이지도 않은 그 메소드 하나만 후킹을 하려고 하면 꼭 System.BadImageFormatException - "Bad class token" 예외가 발생하는 것이었습니다.
오류를 재현하려고 해당 메소드의 코드를 IL 레벨에서 복사를 한 다음, 제가 만든 동일한 VB 소스 코드로 옮겨 보았으나 이제는 오류가 발생하지 않았습니다. 즉, 그 VB.NET 어셈블리에 바로 그 코드가 존재했을 때에만 오류가 발생하는 희한한 현상이었던 것입니다.
조사 결과, GetILFunctionBody의 메소드 크기를 반환하는 것에 버그가 있다는 것을 알게 되었습니다.
예를 들어, 원래 메소드의 크기가 200byte라면 GetILFunctionBody는 198byte를 반환하는 현상이 발생한 것이었습니다. 혹시나 검색을 해보았더니, 정말 그와 같은 이야기가 나옵니다.
BUG: GetILFunctionBody returns wrong size
; http://blogs.msdn.com/b/davbr/archive/2008/05/22/bug-getilfunctionbody-returns-wrong-size.aspx
ICorProfilerInfo::GetILFunctionBody doesn't return the correct size on methods with SEH?
; http://social.msdn.microsoft.com/forums/en-US/netfxtoolsdev/thread/88fe07e0-6e4a-4334-bd09-b760e3c7b455/
정리해 보면, CLR 2.x의 버그인데 GetILFunctionBody 가 메소드의 실제 크기보다 더 크게 반환할 수 있다는 것입니다. IL 코드 영역이 DWORD 정렬이 되어야 해서 0 ~ 3바이트 정도 패딩이 될 수 있는데 패딩의 2배 범위내로 오차가 발생하므로 0 ~ 6바이트 정도의 차이가 있다는 것입니다.
재미있는 것은 위의 문서는 실제 크기보다 더 많게 반환된다는 문서였고, 제 경우에는 2바이트 적게 반환된다는 점이었습니다. 왜 2바이트였을까요? 가만 보니 그 메소드의 IL 코드 패딩이 2바이트였습니다. 그것이 우연의 일치였는지, 전혀 다른 이유에서였는지에 대해서는 알 수 없습니다. 어쨌든, CLR 4부터는 이런 문제가 없어졌겠지만 CLR 2.x를 대상으로 하는 Profiler를 만드는 분들은 이점에 주의를 해야 합니다.