"Module 'testprog' has entry point outside the code (as specified in the PE header). Maybe this file is self-extracting or self-modifying. Please keep it in mind when setting breakpoints!"

Why do I keep receiving this message when I run a sample program I've written with NASM? Does anyone else experience the same thing when running programs they've written and assembled in NASM, in other words is this just the how this assembler functions? Maybe it's just something I'm doing, here is my code:

;;;;;;;;;;;;;BEGIN CODE
%include "INC\win32n.inc"

EXTERN GetModuleHandleA
IMPORT GetModuleHandleA kernel32.dll
EXTERN RegisterClassExA
IMPORT RegisterClassExA user32.dll
EXTERN CreateWindowExA
IMPORT CreateWindowExA user32.dll
EXTERN GetMessageA
IMPORT GetMessageA user32.dll
EXTERN DispatchMessageA
IMPORT DispatchMessageA user32.dll
EXTERN ExitProcess
IMPORT ExitProcess kernel32.dll
EXTERN DefWindowProcA
IMPORT DefWindowProcA user32.dll
EXTERN PostQuitMessage
IMPORT PostQuitMessage user32.dll
EXTERN MessageBoxA
IMPORT MessageBoxA user32.dll
EXTERN SendMessageA
IMPORT SendMessageA user32.dll
EXTERN TranslateMessage
IMPORT TranslateMessage user32.dll
EXTERN ShowWindow
IMPORT ShowWindow user32.dll
EXTERN DefWindowProcA
IMPORT DefWindowProcA user32.dll

segment .data USE32

wcx:
istruc WNDCLASSEX
at WNDCLASSEX.cbSize, dd WNDCLASSEX_size
at WNDCLASSEX.style, dd 0
at WNDCLASSEX.lpfnWndProc, dd WndProc
at WNDCLASSEX.cbClsExtra, dd 0
at WNDCLASSEX.cbWndExtra, dd 0
at WNDCLASSEX.hInstance, dd 0
at WNDCLASSEX.hIcon, dd 0
at WNDCLASSEX.hCursor, dd 0
at WNDCLASSEX.hbrBackground, dd COLOR_WINDOW
at WNDCLASSEX.lpszMenuName, dd 0
at WNDCLASSEX.lpszClassName, dd Windowclassname
at WNDCLASSEX.hIconSm, dd 0
iend

Windowname dd "Test Window!",0
Windowclassname dd "classname",0
Windowhandle dd 0

mMSG dd 0,0,0,0,0,0,0

WindowMessage_1 dd "THIS IS A TEST!",0

segment .code USE32

;..start
mainentry:

push dword 0
call [GetModuleHandleA]

mov [wcx+WNDCLASSEX.hInstance], eax

push dword wcx
call [RegisterClassExA]

push dword 0
push dword [wcx+WNDCLASSEX.hInstance]
push dword 0
push dword 0
push dword 500
push dword 500
push dword CW_USEDEFAULT
push dword CW_USEDEFAULT
push dword WS_OVERLAPPEDWINDOW
push dword Windowname
push dword Windowclassname
push dword WS_EX_CLIENTEDGE
call [CreateWindowExA]
mov [Windowhandle], eax

push dword SW_SHOW
push dword [Windowhandle]
call [ShowWindow]

MessageLoop:
push dword 0
push dword 0
push dword 0
push dword mMSG
call [GetMessageA]
or eax, eax
jz QuitProg
push dword mMSG
call [TranslateMessage]
push dword mMSG
call [DispatchMessageA]
jmp MessageLoop

QuitProg:
push dword 0
call [ExitProcess]

WndProc:
push ebp
mov ebp, esp

cmp dword [ebp+12], WM_CLOSE
je CloseMSG
cmp dword [ebp+12], WM_LBUTTONDOWN
je MouseDown

push dword [ebp+20]
push dword [ebp+16]
push dword [ebp+12]
push dword [ebp+8]
call [DefWindowProcA]

_end:

mov esp, ebp
pop ebp

ret 16

CloseMSG:
push dword 0
call [PostQuitMessage]
xor eax, eax
jmp _end
MouseDown:
push dword MB_OK
push dword Windowname
push dword WindowMessage_1
push dword 0
call [MessageBoxA]
jmp _end
;;;;;;;;;END CODE

the file is packed with an exe packer
try get peid to check the file !!
seems its not a prg of ur own so dont expect much help in this board since its not allowed to talk about cracking here :-)

Umm, I think the guy stated that the program was the one whose source he posted?

Zov: the PE header is not correctly filled and OD thinks it is packed.

psyCK0: Thank you for actually reading my post. Yes, this is my code and is the program I'm receiving this message from.

TBD: OK I see. I thought the problem may have been NASM's ..start symbol used to specify the entry point. So I replaced it with:

global mainentry
mainentry:

and then specified the entry with alink and when I attach to the process it still says it. How exactly does the program run if the entry point is outside the code?

I'm assembling and linking as follows:

With symbol ..start:

nasmw -fobj testprog.asm
alink -oPE testprog

With global entry:
nasmw -fobj testprog.asm
alink -oPE -entry mainentry testprog.obj

This isn't necessarily a problem, but it's driving me insane when I try to debug my ASM programs.

sorry my bad :-)

Zov:I think it is Nasm fault that is not PE 100% compliant.
you can see the PE header in OD
1.Executable modules,
2.right click on your module,
3.View executable file,
4.right click,
5.Special|PE Header

I had the same problem with nasm and Olly. Google told me to check this this ("http://sourceforge.net/mailarchive/forum.php?thread_id=3297563&forum_id=35705") post of the nasm-users mailinglist.
The solution: add "class=code" to the segment declaration:

segment .code USE32 class=code

This way Olly will find the correct entry point.