Hi!

I have written a tool to help coding Activex project. First I wrote it in VB. A while ago I opened a thread in the COM section with a tutorial and a demo. Now I can't find the thread so I suppose it has been deleted.

With help from the VB tool I have rewritten the tool in assembler as an addin for RadAsm.

For those who are interested I attach the dll, an Excel automation demo (ComDemo.zip) and a skeleton project for Excel automation coding (ComTut.zip). You only have to complete the skeleton with coding from the tool. Unzip ComTool.dll, Com.mdb, TLBINF32.DLL and ComTut.chm int RadAsm/Addins folder.
Posted on 2004-09-22 12:13:28 by minor28
Hi minor28

Interesting tool.

Bugs:
1. Looks for the com.mdb in C:\projects\.......
2. GPF's immediatly on Win98SE

KetilO
Posted on 2004-09-22 15:22:04 by KetilO
Sorry for the hardcoded path. Forgot to change.

About GPF's immediatly on Win98SE. I don't have SE. But it works on my Win98 4.10.1998

I also tested on a Win2K machine. There I got a fault. Only buttons and the statusbar was shown. The buttons did work though.

Attach a new dll.
Posted on 2004-09-23 10:17:48 by minor28
If the quick search menu items don't work list all components and rightclick on the component you want to access directly.
Posted on 2004-09-23 10:24:35 by minor28
Hi minor28

Still GPF's on Win98SE

Maybe this will help:

RADASM for?rsaket en ugyldig sidefeil i
modul COMTOOL.DLL ved 0177:0130552d.
Registre:
EAX=00000000 CS=0177 EIP=0130552d EFLGS=00010203
EBX=006ccece SS=017f ESP=006cac4c EBP=006cce7c
ECX=00000000 DS=017f ESI=00008ef2 FS=1a87
EDX=00008f0e ES=017f EDI=006cce84 GS=2117
Byte ved CS:EIP:
52 57 56 68 57 65 30 01 55 54 68 fa 16 30 01 64

KetilO
Posted on 2004-09-23 13:54:13 by KetilO
Hi KetilO

I can't find the eip. It doesn't mach to my win98.

I have SEH in every process but DLLEntry, InstallDLL and DLLProc. In the attached version I have competed with SEH in those too. It will tell me which process it is.
Posted on 2004-09-23 15:11:23 by minor28
Hi

The SEH does not work, also the jit debugger does not catch this GPF.

I have made comtool the only addin in RadASM 2.1.0.0 and EIP is now:

RADASM for?rsaket en ugyldig sidefeil i
modul COMTOOL.DLL ved 0177:00c1557d.
Registre:
EAX=00000000 CS=0177 EIP=00c1557d EFLGS=00010203
EBX=006cce8a SS=017f ESP=006cac08 EBP=006cce38
ECX=00000000 DS=017f ESI=00008eae FS=2987
EDX=00008eca ES=017f EDI=006cce40 GS=3bbf
Byte ved CS:EIP:
52 57 56 68 a7 65 c1 00 55 54 68 48 17 c1 00 64

KetilO
Posted on 2004-09-23 15:46:33 by KetilO
Hi

OllyDbg shows:
Posted on 2004-09-23 16:03:16 by KetilO
Hi

That is the preservation of edx, edi and esi in the main dlg process. That's why the SEH didn't work. I removed the edx.
Posted on 2004-09-23 16:22:06 by minor28
Did not help, crashes on XP SP2 too.
Seem like you are allocating a lot of stack space in that proc.

KetilO
Posted on 2004-09-23 16:34:52 by KetilO
That's strange.

It works on my XP SP1 and my win98. I will try on another machine tomorrow. This is the code.
.if ecx==IDComTool

.if hMainDlg==0
mov osi.dwOSVersionInfoSize,sizeof osi
mov osi.szCSDVersion,128
invoke GetVersionEx,addr osi
.if eax==TRUE
.if osi.dwPlatformId==VER_PLATFORM_WIN32_WINDOWS ;=1 win95/98
;osi.szCSDVersion = (A=Windows 98 SE,C=Windows 95 OSR2)
mov colref,00C0C0C0h ;win98

.elseif osi.dwPlatformId==VER_PLATFORM_WIN32_NT ;=2 winNT
mov colref,00C8D0D4h ;win2K

.endif
.endif
invoke DialogBoxParam,hInstance,IDD_DIALOG1,0,addr MainDlgProc,NULL
.else
invoke SetWindowPos,hMainDlg,HWND_TOP,0,0,0,0,SWP_NOSIZE or SWP_NOMOVE
.endif
.endif
mov eax,FALSE
jmp lbl_finally

MainDlgProc proc uses  edx edi esi hWin:HWND,uMsg:UINT,wParam:WPARAM,lParam:LPARAM

LOCAL buffer[4096]:byte
LOCAL buffer2[256]:byte
LOCAL buffer3[256]:byte
LOCAL printout[4096]:byte
LOCAL pos:dword
LOCAL hdi:HD_ITEM

;_try
push lbl_finally ;address of safe place after guarded code
push ebp ;stack frame
push esp
assume fs:nothing
push offset ED_31 ;address of frame-based exception director
push fs:[0];address of next error structure
mov fs:[0], esp ;save the error address

.if uMsg==WM_INITDIALOG
push hWin
pop hMainDlg
invoke CoInitializeEx,0,0


I will be back tomorrow. Good Night.
Posted on 2004-09-23 16:44:02 by minor28
Hi minor28

Allocating large buffers on stack is not a good idea.
Remember that memory under windows is virtual and must be allocated.
Allocate some stringspace instead.

KetilO
Posted on 2004-09-24 04:17:04 by KetilO
Hi KetilO,

Locals are only 9k. Default stack size is 1 MB. It shouldn't have an critical effect, but it looks like it as the GPF occurs when the edx is pushed on the stack. To change the local buffers to globals will be quite a job.

The dll works on my XP and win98. It also works on another XP.

On my win2k the main dialog only shows the buttons and the statusbar. Neither the dialog itself nor the listview nor menu is visible. The close button works.

The standalone exe works on all machines. I attach the exe if you want to test.
Posted on 2004-09-24 11:16:11 by minor28
Check the post for a possible solution.

http://www.asmcommunity.net/board/viewtopic.php?t=13525&highlight=touch+stack

I ran into this using an early version of Ketilo's very fine Spreadsheet Control.

hth

farrier
Posted on 2004-09-25 09:04:10 by farrier
I have tested with link option STACK but I couldn't see any change.

When I removed the exception handling from the MainDlgProc the main dialog worked on the win2k machine. The other dialog window still don't show up just the controls. So I suppose there must be somethin wrong with the exception handling in the dialog processes.

Are there anyone else who have tested the dll and experienced the same problem as KetilO?

I attache the dll without the exception handling in the main dialog process.
Posted on 2004-09-26 12:00:21 by minor28
minor28,

If you look at the last post in the article I referenced, you'll notice that the problem was due to a large LOCAL variable size. You can use the method I described--stolen from Jeremy Gordon, JORGON--to "touch" the stack gradually, so as not to violate the "guard pages" of the stack.

Nothing I could do with the link or assemble STACK commands could avoid this problem, only touching. So touch your stack, and watch it grow :lol:

hth

farrier
Posted on 2004-09-26 12:40:15 by farrier
Hi farrier,

I don't understand. Do you mean this code
   MOV   ECX,10 

L0:
SUB ESP,1000h
MOV D[ESP],0 ;MOV DWORD ptr ESP, 0
LOOP L0

And adding:
ADD ESP, 0a000h
will "touch" the stack and commit more stack memory? I don't know how to use it.

The strange thing is why I don't get the GPF and the addin works without any problems.
Posted on 2004-09-26 13:41:16 by minor28
minor28,

The problem is not having reserved stack or committed stack, the problem is when you try to cross a boundary "guard page" which WINDOWS sets up to prevent applications from accessing memory they shouldn't. The OS sets a boundary of 4096 bytes away from previously "touched" or used or accessed stack memory, and if you try to jump over the boundary without first using or touching or accessing the memory in between, on some systems you will generate a GPF.

When I first experienced this problem, I was using a WIN95 system and used a new version of KetilO's spreadsheet program. Obviously, it worked on KetilO's machine, but on mine: GPF!

The code you quoted from my post did just what I've decribed:
Added -1000h (-4096) to the stack (ESP),
mov'd a 0 to that stack location
and looped 10 times to touch 40960 bytes worth of stack.
Then I added a000h (40960) to the stack (ESP) to go back to the original value.

In you program you allocate:



LOCAL buffer[4096]:byte
LOCAL buffer2[256]:byte
LOCAL buffer3[256]:byte
LOCAL printout[4096]:byte
LOCAL pos:dword
LOCAL hdi:HD_ITEM


Add up the number of bytes in all these LOCAL's and touch just that many bytes worth of stack, and "maybe" :?: the problem will go away.

All I can tell you is that your problem looks just like the one I had.

hth

farrier
Posted on 2004-09-26 18:34:33 by farrier
minor28,

Another explaination of why your program crashed at the:
	push edx



command. Considering the LOCAL's you declared:

   LOCAL buffer[4096]:byte

LOCAL buffer2[256]:byte
LOCAL buffer3[256]:byte
LOCAL printout[4096]:byte
LOCAL pos:dword
LOCAL hdi:HD_ITEM


Something similar to the following code would be generated
as the first instructions of your procedure, assuming the
standard PROLOGUE code:

push	ebp

mov ebp, esp
add esp, -size_of_locals


Where size_of_locals is the total number of bytes of all
your LOCAL's. Since size_of_locals is greater than 2 X 4096,
when you push edx, you are gauranteed to cross the gaurd
page boundary the OS sets up.

There is probably a macro or some other clever way to
determine the size_of_locals.

At this point, you need to "touch" memory every 4096 bytes
from the original ESP when we entered the proc, to the
current esp. To do this, maybe you could:

	mov	eax, esp		;manipulate this value in eax

add eax, size_of_locals ;to restore value of orig. ESP
touch: mov dword ptr [eax], 0
sub eax, 4096
cmp esp, eax
jle touch


This would only corrupt eax, and touch the pages of memory
used by the LOCAL's. Unless I've made a mistake.

See attached file!

hth

farrier
Posted on 2004-09-27 21:32:18 by farrier
Thanks for you efforts to help me but the problem is that my program don't crash on my computer. As far as I know nobody else but KetilO has reported a crash.

KetilO. I suggest that you delete my thread. I will follow your advice and open a new thread when I have revised the dll.

Best regards
Posted on 2004-09-28 00:38:08 by minor28