일단 검사하시려면 FastMM를 사용해서 제거하세요.
보통 일반 배열은 setlength(la, 0)만 해도 메모리 릭을 제거 할 수 있지만, 오브젝트가 별도 생성해서 연결하는 경우, 예로 콤보 아이템에 오브젝트 연결등에서 별도로 만든 구조체 생성한걸 연결하면, 나중에 루프로 free하시는게 좋습니다.
그래서 구조체 자체에도 constructor Create;와 destructor Destroy;를 만드는 습관도 좋습니다.

홍성락님
프로젝트파일의 uses절 제일 처음에 fastmm4를 추가하고 다시 컴파일한후에 검사해보았지만 같은 결과가 나왔습니다.
혹 제가 fastmm4를 잘못 쓴게 아닌지.
관심 돌려주셔서 감사합니다.

fastmm4는 메모리릭을 찾아주는거지 없애주는건 아닙니다, 누적되거나 큰 릭이 발생하면 잡아줘야합니다, 즉 레코드 생성시 재확인하여 전에 있는 쓰레기가 있는지, 완료시에도 깨끗이 처리를 하셔야합니다. 본 프로그램 릭이 아니라면 다른것으로 인해서 어플이 죽는겁니다, 예외처리 부분도 보십시요

홍성락님 감사합니다.
ocx테스트가 힘들어 exe로 만들어 보니 다음의 로그 파일이 생기는데요 이게 대체 뭔 소린지 알수 없습니다.
A memory block has been leaked. The size is: 36

This block was allocated by thread 0xFA0, and the stack trace (return addresses) at the time was:
402E60
403C17
403FB2
434652
4047BB
4C492F
404713
40477B
406FDB
50A4B4
7C92DC9C [ZwSetInformationThread]

The block is currently used for an object of class: TCriticalSection

The allocation number is: 598

Current memory dump of 256 bytes starting at pointer address 7FF864E0:
20 46 43 00 70 79 14 00 FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70 88 D2 00
88 7F 51 00 88 7F 51 00 00 00 00 00 21 67 F8 7F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
59 02 00 00 E5 2E 40 00 4F 2D 42 00 F1 2A 42 00 B9 2B 42 00 74 28 42 00 95 1C 4C 00 76 BA 80 7C
A5 17 AD 00 BB 01 93 7C B6 14 93 7C F4 14 93 7C A0 0F 00 00 CC 2E 40 00 4F 2D 42 00 00 28 42 00
7B 3C 40 00 7B 22 4C 00 A3 46 40 00 62 49 40 00 01 A5 50 00 9C DC 92 7C 67 70 81 7C 70 70 81 7C
A0 0F 00 00 20 00 00 00 00 00 00 00 BA 51 2C EC 88 7C 51 00 88 7F 51 00 88 7F 51 00 88 7F 51 00
88 7F 51 00 88 7F 51 00 88 7F 51 00 88 7F 51 00 45 AE D3 13 88 7F 51 00 00 00 00 00 D1 67 F8 7F
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 64 02 00 00 60 2E 40 00 17 3C 40 00 B2 3F 40 00
F C . p y . .     . . . . . . . . . . . . . . . . p ? ? .
?  Q . ?  Q . . . . . ! g ?  . . . . . . . . . . . . . . . .
Y . . . ? . @ . O - B . ? * B . ? + B . t ( B . ? . L . v ? € |
? . ? . ? . ? | ? . ? | ? . ? | ? . . . ? . @ . O - B . . ( B .
{ < @ . { " L . ? F @ . b I @ . . ? P . ? ? ? | g p ? | p p ? |
? . . . . . . . . . . ? Q , ? ? | Q . ?  Q . ?  Q . ?  Q .
?  Q . ?  Q . ?  Q . ?  Q . E ? ? . ?  Q . . . . . ? g ? 
. . . . . . . . . . . . . . . . d . . . ` . @ . . < @ . ? ? @ .

--------------------------------2008/10/20 11:50:37--------------------------------
This application has leaked memory. The small block leaks are (excluding expected leaks registered by pointer):

21 - 36 bytes: TCriticalSection x 1

Note: Memory leak detail is logged to a text file in the same folder as this application. To disable this memory leak check, undefine "EnableMemoryLeakReporting".

TCriticalSection x 1... 이정도 작은 릭이면 잡을 필요도 없습니다, 특정 메모리에 누적도 없이 생기는거라 찾기도 힘들지만 다른 영향은 없을겁니다. 의심이 가는 부분을 반복해서 테스트해보세요. 만약을 위해 위레서 말씀드린것 처럼 소스상에 예외사항을 잘 주었나 아니면 특정 루틴이 ie에 탑재될때 동시 수행부분에 Interval을 줘야한다든지, 아니면 ocx탑재를 야러번 하고 있다든지 등등을 확인해 보세요

이용한 서고들이 충돌하는가를 검사하려고 새 프로젝트에 빈 폼을 만들고 uses절을 복사한 후 하나씩 제거해해본 결과 우의 메모리 릭이 인디때문에 생긴다는걸 발견했습니다. uses 에 인디에 관련된것이 하나만 있어도 우의 통보가 뜹니다.
이건 인디의 버그겠지요? 저는 델파이 7에 내장된 인디 9를

indy도 그럴겁니다, 저희도 메모리릭중 누적도 없는 xx - xx bytes: TCriticalSection x 1 이런건 잡을 생각도 안합니다

홍성락님 많은 도움주셔서 정말 감사합니다.

EXE로 만드셨다면, EurekaLog 라는 것을 이용해서 보세요. 도움이 되실 것입니다. 메모리 릭이 어느부분에서 발생하는지 대부분 알려줍니다.