Delphi 10.4 + msbuild = unstable binary - delphi

Question

I just implemented a CI/CD environment with Delphi 10.4+gitlab+build machine
Everything worked apparently correct, with the build process running smoothly, but when using the program, it randomly show errors that never occurs compared if I build manually via "shift+F9" (build) inside Delphi itself.
The build process:
call "C:\\Program Files (x86)\\Embarcadero\\Studio\\21.0\\bin\\rsvars.bat"
msbuild /target:rebuild /property:config=Debug;DCC_BuildAllUnits=true /p:platform=Win32 project.dproj
Also, I tried other msbuild variations like:
msbuild /target:rebuild /property:config=Debug /p:platform=Win32 project.dproj
(and also with 2 steps (target:clean and target:build)
I also compared msbuild dcc32.exe command with "Delphi" dcc32.exe command, and they are basically equal but for an additional (inexistent) folder for msbuild output:
-I"c:\program files (x86)\embarcadero\studio\21.0\lib\Win32\release\EN";...
The weirdest thing is: after doing a msbuild build, if I open my project with Delphi, do a clean+compile the program became weirder, giving other errors, but if I do full build (shift+F9) then it runs smoothly again
To me, it looks like some of the components used aren't properly compiled under msbuild or are used with other parameters, but I have no idea of what could it be or how to find it.
Error I got after building with cmd msbuild + clean at Delphi + compile at Delphi:
First chance exception at $0019FB95. Exception class $C0000096 with message 'privileged instruction at 0x0019fb95'. Process project.exe (11324)
Followed by:
First chance exception at $0040AE84. Exception class $C0000005 with message 'access violation at 0x0040ae84: read of address 0x0000000b'. Process project.exe (11324)
Looking at the error, it is raised in this code:
procedure TAdvancedField.asImageLoadToBitMap(var outBitmap:TBitmap); var FS : TMemoryStream;
FirstBytes: AnsiString;
Graphic : TGraphic;
begin try
FS := TMemoryStream.Create;
(Self as TBlobField).SaveToStream(FS);
fs.Position := 0;
SetLength(FirstBytes, 8);
FS.Read(FirstBytes[1], 8);
//Graphic := nil; //I add this line after my debug, and commented to confirm
//if Copy(FirstBytes, 1, 2) = 'BM' then
//begin
// Graphic := TBitmap.Create;
//end else
//if FirstBytes = #137'PNG'#13#10#26#10 then
//begin
// Graphic := TPngImage.Create;
//end else
//if Copy(FirstBytes, 1, 3) = 'GIF' then
//begin
// Graphic := TGIFImage.Create;
//end else
//if Copy(FirstBytes, 1, 2) = #$FF#$D8 then
//begin
// Graphic := TJPEGImage.Create;
// TJPEGImage(Graphic).CompressionQuality := 100;
//end;
if Assigned(Graphic) then
begin
try
FS.Seek(0, soFromBeginning);
Graphic.LoadFromStream(FS); //The error raised HERE
outBitmap.Assign(Graphic);
except
end;
Graphic.Free;
end
else
begin
outBitmap.Assign(nil);
end;
finally
fs.Free;
end;
end;
As you can see, the Graphic variable isn't initialized anywhere. But with a clean Delphi build it runs perfectly with Assigned(Graphic) always returning false, but after msbuild it returns as true. If this is correct to other similar cases it'll lead to unexpected behavior all across the project.
Another situation:
I put a button at my main form with a single raise exception, + application exception handler + JCVStackTrace handler, and this is the captured stack:
[017B7DE5] pcnConversao.RegTribISSQNToStr (Line 1301, "pcnConversao.pas" + 1) + $104
[006B6973] Vcl.Controls.TWinControl.ArrangeControl + $147
[006BB36F] Vcl.Controls.TWinControl.DoKeyUp + $73
[005A4998] Vcl.StdCtrls.TCustomCheckBox.SetChecked + $0
[006BB4CF] Vcl.Controls.TraverseControls + $37
[006BB36F] Vcl.Controls.TWinControl.DoKeyUp + $73
[0067E227] Vcl.Forms.TCustomForm.CreateWnd + $97
[006BA8BC] Vcl.Controls.TWinControl.WMInputLangChange + $8
[004F4A18] System.Classes.TStreamWriter.WriteLine + $C
[006BB47A] Vcl.Controls.TWinControl.WMChar + $2
[006BB36F] Vcl.Controls.TWinControl.DoKeyUp + $73
[005A4998] Vcl.StdCtrls.TCustomCheckBox.SetChecked + $0
[004F4A18] System.Classes.TStreamWriter.WriteLine + $C
By the way, pcnConversao is only used indirectly by my project
The correct would be:
[01709661] UModulo.TModulo.BitBtn3Click (Line 568, "UModulo.pas" + 0) + $11
[006BB3E7] Vcl.Controls.TWinControl.WndProc + $693
[005A4A10] Vcl.StdCtrls.TButtonControl.WndProc + $6C
[006BB547] Vcl.Controls.DoControlMsg + $23
[006BB3E7] Vcl.Controls.TWinControl.WndProc + $693
[0067E29F] Vcl.Forms.TCustomForm.WndProc + $6DB
[006BA934] Vcl.Controls.TWinControl.MainWndProc + $2C
[004F4A90] System.Classes.StdWndProc + $14
[006BB4F2] Vcl.Controls.TWinControl.DefaultHandler + $E6
[006BB3E7] Vcl.Controls.TWinControl.WndProc + $693
[005A4A10] Vcl.StdCtrls.TButtonControl.WndProc + $6C
[004F4A90] System.Classes.StdWndProc + $14
Note:
Looks like the different stack is directly related with Stack Frames checked at Delphi Compiler->Compiling->Code Generation, still no related with the diverging way of the compiler at not initialized variable

Answer 1

The problem was exactly that uninitialized variable. Still don't know why the behavior was different from the default build trough the IDE, but initializing as nil solved the problem