Reputation: 2150
I have a simple Delphi program with an open file dialog
unit Unit1;
interface
uses
Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls;
type
TForm1 = class(TForm)
Button1: TButton;
procedure Button1Click(Sender: TObject);
end;
var
Form1: TForm1;
implementation
{$R *.dfm}
procedure TForm1.Button1Click(Sender: TObject);
var
openDialog : TOpenDialog;
i : Integer;
begin
openDialog := TOpenDialog.Create(self);
openDialog.InitialDir := GetCurrentDir;
if not openDialog.Execute
then ShowMessage('Open file was cancelled')
else
begin
end;
openDialog.Free;
end;
end.
This seems to work ok when I click the button on the form and cancel the file open dialog.
However, after doing this, when I leave the program running I get an access violation.
Could this be a bug in XE6 ?
EDIT
Just in case any of you were wondering if my windows is up to date
EDIT
Here is a list of the error messages I get:
Upvotes: 2
Views: 1732
Reputation: 58491
I first ran analyze -v
on your dump. Unfortunately and surprisingly that did not turn up anything usefull.
Next attempt was to look at all stacks using (~*)
. This did turn up following interesting stack.
10 TID:1a08 kb kbn kbnL kn knL kpn kPn
# ChildEBP RetAddr
00 0668f128 77c7b230 ntdll!RtlLookupFunctionTable+0x85
01 0668f178 77c7b3f5 ntdll!RtlIsValidHandler+0x26
02 0668f1f8 77c30133 ntdll!RtlDispatchException+0x10e
03 0668f1f8 0668f7b1 ntdll!KiUserExceptionDispatcher+0xf
WARNING: Frame IP not in any known module. Following frames may be wrong.
04 0668f6c0 77c7b499 0x668f7b1
05 0668f6e4 77c7b46b ntdll!ExecuteHandler2+0x26
06 0668f708 77c7b40e ntdll!ExecuteHandler+0x24
07 0668f794 77c30133 ntdll!RtlDispatchException+0x127
08 0668f794 7632c99e ntdll!KiUserExceptionDispatcher+0xf
09 0668fc84 76335d00 ole32!CStdMarshal::Disconnect+0x223
0a 0668fc98 76335ce1 ole32!DisconnectSwitch+0x16
0b 0668fcb0 76335d3f ole32!CStdMarshal::DisconnectAndRelease+0x44
0c 0668fe60 76368f82 ole32!COIDTable::ThreadCleanup+0xcb
0d 0668fea4 76368ec3 ole32!FinishShutdown+0x9d
0e 0668fec4 7635bac3 ole32!ApartmentUninitialize+0x96
0f 0668fedc 763688e8 ole32!wCoUninitialize+0x153
10 0668fef8 6ef2314a ole32!CoUninitialize+0x72
11 0668ff00 764943c0 NetworkItemFactory!FDBackgroundThreadHandler+0x21
12 0668ff88 7662338a shlwapi!WrapperThreadProc+0x1b5
13 0668ff94 77c59f72 kernel32!BaseThreadInitThunk+0xe
14 0668ffd4 77c59f45 ntdll!__RtlUserThreadStart+0x70
15 0668ffec 00000000 ntdll!_RtlUserThreadStart+0x1b
At least, this confirmed our first suspicion that it is COM/system related, not Delphi. Digging into the stack looking for usefull strings turned up following string
d:\w7rtm\com\ole32\com\class\compobj.cxx
Now we have something new to search for: w7rtm compobj
This lead to the following thread on SO (notice the identical stacktrace)
Crashes in ole32!COIDTable::ThreadCleanup … NetworkItemFactory!FDBackgroundThreadHandler
The question was asked by Thomas W and commented on by Hans Pasant and both are far more knowledgable using WinDbg or Windows Internals without finding a definitive solution (at least, there's no solution posted) so I'm afraid you are left with the following advice Hans gave to Thomas
You are buried inside the COM plumbing with a clear hint that its internal state is corrupted. This is an environmental problem, some kind of DLL that gets injected into the process and screws things up. Long before the crash occurs so you'll have very little hope of diagnosing it with a debugger. Find the common source of the problem from the modules list. Suspect any shell extension, anti-malware, any utility similar to Dropbox. Use SysInternals' AutoRuns to disable them. (Hans Pasant)
Assuming the fault is in a dll injected into your process, I have taken a cross section of the loaded dll's from your dump and from the application running on my computer (it doesn't crash on my computer) leaving following suspect dll's
ATL90 EhStorAPI EhStorShell FWPUCLNT GROOVEEX_64a40000 GrooveIntlResource_63d20000 MsftEdit OFFICE RpcRtRemote TortoiseSVN32 TortoiseStub32
WMASF WMVCore WSHTCPIP WcnApi Wldap32 atl atl100 audiodev cfgmgr32 crypt32 cryptsp
davhlpr devobj dnsapi dui70 duser fdWNet fundisc gdiplus gdiplus ieframe ieproxy
iertutil imm32 intl3_tsvn32 kernel32 libapr_tsvn32 libaprutil_tsvn32 libsasl32 libsvn_tsvn32 linkinfo lpk mpr
msasn1 msctf msls31 msvcp100 msvcp110 msvcp90 msvcr100 msvcr110 msvcr90 msxml6 netmsg
normaliz nsi ntmarta psapi rpcrt4 secur32 setupapi shdocvw shlwapi slc sspicli
userenv usp10 wininet winmm winnsi winsta wintrust wpdshext wpdshext ws2_32 wship6 xmllite
api_ms_win_downlevel_advapi32_l1_1_0
api_ms_win_downlevel_normaliz_l1_1_0
api_ms_win_downlevel_shell32_l1_1_0
api_ms_win_downlevel_shlwapi_l1_1_0
api_ms_win_downlevel_shlwapi_l2_1_0
api_ms_win_downlevel_user32_l1_1_0
api_ms_win_downlevel_version_l1_1_0
If we leave out all Microsoft's and Unloaded dll's, following dll's remain
TortoiseSVN32
TortoiseStub32
intl3_tsvn32
libapr_tsvn32
libaprutil_tsvn32
libsasl32
libsvn_tsvn32
So my first try on your system would be to either uninstall or disable loading of (using autoruns) the TortoiseSVN plugin and see if that solves your problem.
Upvotes: 2
Reputation: 54832
You have a "first chance exception" in ole32.dll. Not getting any errors when the program is run outside the debugger (as stated in the comments) is an indication of that. Always suspect first chance exceptions when it refers to a seemingly pseudo address, like 0xFEEEFEEE as in this case. Don't suspect for long though, check the "event log" debug window of the IDE, you should see an entry like "First chance exception at ....".
A first chance exception means code has encountered an exceptional case. It doesn't mean that the exception will not be handled. That's like an exception you yourself raise in your code. For an external debugger that's a first chance exception.
There's nothing to do or worry about here. You don't have to try and avoid having the exception with workarounds or anything as long as the the program proceeds normally after that.
Upvotes: 2