Dealing with this via support email due to the specific nature of the issue.

--
Tim Young
Elevate Software
www.elevatesoft.com

Not sure if I'm narrowing down the issue somewhat. Might be related to
the change in Windows 2008 of InitializeCriticalSection and
InitializeCriticalSectionEx.

Seems the memory isn't greating released correctly using
InitializeCriticalSection in 2008 and even maybe Vista.

CS uses a lot of threading, as does things like KBMmw.

Is there a solution to this changing from InitializeCriticalSection to
InitializeCriticalSectionEx, or maybe it is a bug in the 32bit Kernel
of 2008. 2008 64bit isn't having these issues going on the above
posts? Is the 2008 64bit releasing your Delphi apps' resources, etc?

http://stackoverflow.com/questions/804848/critical-sections-leaking-memory-on-vista-win2008
http://stackoverflow.com/questions/780073/is-the-memory-not-reclaimed-for-delphi-apps-running-on-windows-server-2008-sp1

Not sure quite how to implement these changes quite - any direction?

I think this code is right. I'm in Delphi5, so correct me if the
latest version of Delphi has fixed this? Basically MS has added debug
info to the InitializeCriticalSection, that it doesn't free so you
have to use InitializeCriticalSectionEx. Quite how I do this in code
of 3rd parties I'm not sure.

KBMmw I'll have to doctor but not even sure I have the source code to
DBISAM 3. Does the DBISAM 3 engine use threads? I know my KBMmw system
does and I'll need to sort it out.

Add to this what's the best way to detect an OS and implement a
change? Can I load in the Windows.pas into my project and doctor the
source there to affect KBMmw and DBISAM in my code, etc?

Can I maybe have a compiler option to build a Win XP and a 2008
version? Areas I'm not too clued up on. Any assitance would be
welcome.

Taken a bloody age to narrow this beauty down!

This code will compile in any OS but will only work in Win Server
2008. Run it and use "Process Monitor" to see the RAM use of the
different procedures. The "Normal " is slow, uses more RAM and CPU and
leaves stuff behind. The 2008 method uses less RAM, is way quicker and
releases all threads perfectly.

unit Unit1;

interface

uses
 Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
 StdCtrls, Windows;

type
 TForm1 = class(TForm)
   Button1: TButton;
   Button2: TButton;
   Label1: TLabel;
   procedure Button1Click(Sender: TObject);
   procedure Button2Click(Sender: TObject);
 private
   { Private declarations }
 public

 end;


var
 Form1: TForm1;

function InitializeCriticalSectionEx (var lpCriticalSection:
TRTLCriticalSection;
dwSpinCount: DWORD; Flags: DWORD): BOOL; stdcall; external
'kernel32.dll' name 'InitializeCriticalSectionEx';
const CRITICAL_SECTION_NO_DEBUG_INFO = $01000000;

implementation

const
 CS_NUMBER = 10000000;
type
 TCSArray = Array[1..CS_NUMBER] of TRTLCriticalSection;
 PCSArray = ^TCSArray;

procedure TestStatic;
var
 csArray: PCSArray;
 idx: Integer;
begin
 New(csArray);

 for idx := 1 to length(csArray^) do
   InitializeCriticalSection(csArray^[idx]);

 for idx := 1 to length(csArray^) do
     DeleteCriticalSection(csArray^[idx]);

 Dispose(csArray);
end;

procedure TestStatic2008;
var
 csArray: PCSArray;
 idx: Integer;
begin
 New(csArray);

 for idx := 1 to length(csArray^) do
  InitializeCriticalSectionEx (csArray^[idx], 0,
CRITICAL_SECTION_NO_DEBUG_INFO);

 for idx := 1 to length(csArray^) do
  DeleteCriticalSection(csArray^[idx]);


 Dispose(csArray);
end;

procedure TestDynamic(const Number: Integer);
var
 csArray: array of TRTLCriticalSection;
 idx: Integer;
begin
 SetLength(csArray, Number);

 for idx := Low(csArray) to High(csArray) do
   InitializeCriticalSection(csArray[idx]);

 for idx := Low(csArray) to High(csArray) do
     DeleteCriticalSection(csArray[idx]);
end;

procedure TestDynamic2008(const Number: Integer);
var
 csArray: array of TRTLCriticalSection;
 idx: Integer;
begin
 SetLength(csArray, Number);

 for idx := Low(csArray) to High(csArray) do
   InitializeCriticalSectionEx (csArray[idx], 0,
CRITICAL_SECTION_NO_DEBUG_INFO);

 for idx := Low(csArray) to High(csArray) do
     DeleteCriticalSection(csArray[idx]);

end;

procedure TForm1.Button1Click(Sender: TObject);// Normal
Delphi/Windows Code
begin
 TestStatic;
 TestDynamic(CS_NUMBER);

end;

procedure TForm1.Button2Click(Sender: TObject); // Code required for
Win 2008, Vista and probably Win7
begin
 TestStatic2008;
 TestDynamic2008(CS_NUMBER);

end;

end.

Charles,

There isn't any evidence that the cause of your issue is the critical
sections.  As I mentioned in my email to you, DBISAM 3.x will only use a few
hundred critical sections, even for ~200 tables in a database, and the
problem that the SO poster had was related to using a *lot* of CS's
(millions, in his example).

<< KBMmw I'll have to doctor but not even sure I have the source code to
DBISAM 3. Does the DBISAM 3 engine use threads? I know my KBMmw system does
and I'll need to sort it out. >>

Honestly, I wouldn't mess with this - I think you're chasing a phantom and
you're going to do more harm than good.  Plus, CS's <> threads, so just the
use of threads does not mean that CS's are being used, necessarily.  There
are many types of synchronization, including lock-free primitives that don't
use CS's.

--
Tim Young
Elevate Software
www.elevatesoft.com