sav
sav

Reputation: 2150

TOpenFileDialog Access violation in XE6

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.

access violation

stack trace

Could this be a bug in XE6 ?


EDIT

Just in case any of you were wondering if my windows is up to date

update


EDIT

Here is a list of the error messages I get:

First

Second

Third

Fourth

Upvotes: 2

Views: 1732

Answers (2)

Lieven Keersmaekers
Lieven Keersmaekers

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

Sertac Akyuz
Sertac Akyuz

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

Related Questions