Create Shell Link causes external exception EEFFACE in Delphi 2007 [duplicate] - delphi
While debugging my application with Delphi 2009, I sometimes get the following exception occurring:
(source: beholdgenealogy.com)
This only happens occasionally, but after pressing OK, then my IDE and program both may freeze. If I am lucky I can sometimes do a File/SaveAll in Delphi, but sometimes I can't. Either way I am stuck and then the only thing I can do is use Windows Task Manager to shut down Delphi. Of course, if I was unable to SaveAll, then I lose all the edits I had made since last saving.
I have all the Delphi 2009 Updates installed right up to and including Update 4. I also have IDE Fix Pack 2009 2.9 installed.
The Error is trapped for me by EurekaLog, and the error report gives the following call stack:
Call Stack Information:
-----------------------------------------------------------------------------------------------------------
|Address |Module |Unit |Class |Procedure/Method |Line |
-----------------------------------------------------------------------------------------------------------
|Running Thread: ID=5068; Priority=0; Class=; [Main] |
|---------------------------------------------------------------------------------------------------------|
|205669C6|dbkdebugide120.bpl |Debug.pas |TDebugger |DBKWndProc |11598[6] |
|777DE49A|ntdll.dll | | |KiUserExceptionDispatcher | |
|7705E0CB|kernel32.dll | | |RaiseException | |
|03E8E3E8|dcc120.dll |WRITEOBJ.OBJ | |C62_0 | |
|03E3066D|dcc120.dll |SYMTAB.OBJ | |MakeOverloadedPropertyList| |
|03E3064C|dcc120.dll |SYMTAB.OBJ | |MakeOverloadedPropertyList| |
|03E30D76|dcc120.dll |SYMTAB.OBJ | |EnterMethod | |
|03E30D6C|dcc120.dll |SYMTAB.OBJ | |FindBaseClassMethod | |
|03DE8D30|dcc120.dll |DECL.OBJ | |PatchConstRecordParameter | |
|777DE590|ntdll.dll | | |RtlLeaveCriticalSection | |
|03DBBF70|dcc120.dll |BROWCMGR.OBJ | |PutToAddress | |
|03DBC436|dcc120.dll |BROWCMGR.OBJ | |GetNearestSymName | |
|777DE550|ntdll.dll | | |RtlEnterCriticalSection | |
|219C5BDA|win32debugide120.bpl|Win32Debug.pas |TWin32LinkUnit |GetCppDebugHook |1923[3] |
|219C5BB8|win32debugide120.bpl|Win32Debug.pas |TWin32LinkUnit |GetCppDebugHook |1920[0] |
|219C644E|win32debugide120.bpl|Win32Debug.pas |TWin32Process |DoLinkUnitCreated |2198[10] |
|50001CE4|rtl120.bpl |System.pas | |InterlockedIncrement |3200[0] |
|5000CD59|rtl120.bpl |System.pas |TInterfacedObject |_AddRef |21759[1] |
|2055F40F|dbkdebugide120.bpl |Debug.pas |TProcess |LinkUnitCreated |8454[1] |
|2055F408|dbkdebugide120.bpl |Debug.pas |TProcess |LinkUnitCreated |8453[0] |
|2055CEC7|dbkdebugide120.bpl |Debug.pas |TEvaluatorCallback|ntfyLinkUnitDelta |7167[7] |
|77050DF0|kernel32.dll | | |VirtualProtect | |
|50003FE4|rtl120.bpl |System.pas | |_ReallocMem |3512[0] |
|500093F6|rtl120.bpl |System.pas | |_LStrSetLength |15889[38]|
|50004508|rtl120.bpl |System.pas | |Move |4414[0] |
|5001DDB9|rtl120.bpl |SysUtils.pas | |StrLCopy |7852[5] |
|5007E559|rtl120.bpl |UxTheme.pas | |DrawThemeTextEx |5226[2] |
|5007E524|rtl120.bpl |UxTheme.pas | |DrawThemeTextEx |5224[0] |
|2110A98D|vclactnband120.bpl |ThemedActnCtrls.pas|TThemedMenuButton |DoDrawText |488[23] |
|50009E88|rtl120.bpl |System.pas | |_UStrClr |16961[0] |
|2110A9A2|vclactnband120.bpl |ThemedActnCtrls.pas|TThemedMenuButton |DoDrawText |490[25] |
|75FC7BFE|USER32.dll | | |CallNextHookEx | |
|20AA9C5E|designide120.bpl |DeskUtil.pas | |SetFocusHook |435[4] |
|210E8B83|vclactnband120.bpl |ActnMenus.pas | |CallWindowHook |741[20] |
|50057F7D|rtl120.bpl |Classes.pas |TComponent |UpdateAction |11881[1] |
|50006EE4|rtl120.bpl |System.pas | |_CallDynaInst |10209[0] |
|501EA802|vcl120.bpl |Forms.pas | |ProcessUpdate |6739[1] |
|50006F3C|rtl120.bpl |System.pas |TObject |InheritsFrom |10281[0] |
|50006E1A|rtl120.bpl |System.pas | |_IsClass |10107[1] |
|50006E0C|rtl120.bpl |System.pas | |_IsClass |10106[0] |
|501EA870|vcl120.bpl |Forms.pas | |TraverseClients3 |6756[5] |
|501EA818|vcl120.bpl |Forms.pas | |TraverseClients3 |6751[0] |
|501EA88A|vcl120.bpl |Forms.pas | |TraverseClients3 |6756[5] |
|50047748|rtl120.bpl |Classes.pas |TList |Get |3366[0] |
|501C865E|vcl120.bpl |Controls.pas |TWinControl |GetControl |8473[4] |
|50006F3C|rtl120.bpl |System.pas |TObject |InheritsFrom |10281[0] |
|50006E1A|rtl120.bpl |System.pas | |_IsClass |10107[1] |
|501C8668|vcl120.bpl |Controls.pas |TWinControl |GetControlCount |8478[0] |
|501EA87B|vcl120.bpl |Forms.pas | |TraverseClients3 |6756[5] |
|501EA818|vcl120.bpl |Forms.pas | |TraverseClients3 |6751[0] |
|501EA8E2|vcl120.bpl |Forms.pas |TCustomForm |CMActionUpdate |6778[11] |
|501C565A|vcl120.bpl |Controls.pas |TControl |WndProc |6642[91] |
|501C5388|vcl120.bpl |Controls.pas |TControl |WndProc |6551[0] |
|501C9CE7|vcl120.bpl |Controls.pas |TWinControl |WndProc |9336[136]|
|75FC7C2B|USER32.dll | | |CallNextHookEx | |
|75FCC477|USER32.dll | | |InvalidateRect | |
|75FCC41E|USER32.dll | | |InvalidateRect | |
|75FCC49D|USER32.dll | | |CallWindowProcW | |
|75FCC487|USER32.dll | | |CallWindowProcW | |
|205669A5|dbkdebugide120.bpl |Debug.pas |TDebugger |DBKWndProc |11595[3] |
|500591DC|rtl120.bpl |Classes.pas | |StdWndProc |12703[8] |
|75FC9467|USER32.dll | | |IsWindowVisible | |
|75FC8B0B|USER32.dll | | |DispatchMessageW | |
|75FC8B01|USER32.dll | | |DispatchMessageW | |
|501EEABD|vcl120.bpl |Forms.pas |TApplication |ProcessMessage |9660[30] |
|501EE9A0|vcl120.bpl |Forms.pas |TApplication |ProcessMessage |9630[0] |
|501EEB02|vcl120.bpl |Forms.pas |TApplication |HandleMessage |9690[1] |
|501EEAF8|vcl120.bpl |Forms.pas |TApplication |HandleMessage |9689[0] |
|501EEE2D|vcl120.bpl |Forms.pas |TApplication |Run |9827[26] |
|501EED64|vcl120.bpl |Forms.pas |TApplication |Run |9801[0] |
|004259E6|bds.exe |bds.dpr | |bds |198[8] |
|770CECC9|kernel32.dll | | |BaseThreadInitThunk | |
-----------------------------------------------------------------------------------------------------------
As you can see, all of the call stack is in Delphi and Windows. It does not connect back at all to any line in my program.
I have looked at the webpage: External Exception EEFFACE and translated it from German to English, but it appears to be talking about Delphi C++ whereas I don't use C++ at all.
My problem is I have no idea what might be causing this as it does not happen consistently. I have no idea even where to look to find it or how to track it down.
Does someone know what this is and how I can track it down or at least prevent it from happening?
Alex of EurekaLog posted this in response to my query on their forum:
I think it may be a bug in Delphi's
debugger. Possibly related to
evaluation tooltips or something
similar.
See for yourself - we have an C++
exception in system module (EEFFACE is
a special code for VCL exception. When
VCL encounters an unknown C++
exception - it wraps it into
EExternalException object with code =
EEFFACE) and call stack includes
Delphi debugger's units:
|205669C6|dbkdebugide120.bpl |Debug.pas |TDebugger |DBKWndProc |11598[6] |
|7705E0CB|kernel32.dll | | |RaiseException | |
|03E8E3E8|dcc120.dll |WRITEOBJ.OBJ | |C62_0 | |
|03E3066D|dcc120.dll |SYMTAB.OBJ | |MakeOverloadedPropertyList| |
|03E3064C|dcc120.dll |SYMTAB.OBJ | |MakeOverloadedPropertyList| |
|03E30D76|dcc120.dll |SYMTAB.OBJ | |EnterMethod | |
|03E30D6C|dcc120.dll |SYMTAB.OBJ | |FindBaseClassMethod | |
|03DE8D30|dcc120.dll |DECL.OBJ | |PatchConstRecordParameter | |
|03DBBF70|dcc120.dll |BROWCMGR.OBJ | |PutToAddress | |
|03DBC436|dcc120.dll |BROWCMGR.OBJ | |GetNearestSymName | |
|219C5BDA|win32debugide120.bpl|Win32Debug.pas |TWin32LinkUnit |GetCppDebugHook |1923[3] |
|219C5BB8|win32debugide120.bpl|Win32Debug.pas |TWin32LinkUnit |GetCppDebugHook |1920[0] |
|219C644E|win32debugide120.bpl|Win32Debug.pas |TWin32Process |DoLinkUnitCreated |2198[10] |
|50001CE4|rtl120.bpl |System.pas | |InterlockedIncrement |3200[0] |
|5000CD59|rtl120.bpl |System.pas |TInterfacedObject |_AddRef |21759[1] |
|2055F40F|dbkdebugide120.bpl |Debug.pas |TProcess |LinkUnitCreated |8454[1] |
|2055F408|dbkdebugide120.bpl |Debug.pas |TProcess |LinkUnitCreated |8453[0] |
|2055CEC7|dbkdebugide120.bpl |Debug.pas |TEvaluatorCallback|ntfyLinkUnitDelta |7167[7] |
I think that you should post this
description to Embarcadero's Quality
Central.
Try to disable "IDE integration"
check-box (it's located in IDE's
"EurekaLog"/"EurekaLog IDE Options"
menu) and run your application - see
if there will be a change in behavior.
I have now submitted a report to Quality Central at:
http://qc.embarcadero.com/wc/qcmain.aspx?d=81881
Hopefully with this information, Embarcadero will be able to prevent this in future releases.
I come back to this question over 4 years later, and realize that a few months ago, I found the solution, so I am posting it here for anyone else who may encounter this.
The problem and solution were provided in Olaf Monien's blog, in a post from 2009/07/22 titled Delphi 2009 / Windows 7 / 64 bit Debugger Crash Workaround.
Olaf's instructions on that post worked perfectly for me, and the problem is gone. I thanked him in a comment on his blog post.
As #rossmcm points out in his comment, Olaf's blog post is no longer there, but the post can still be found on the Internet Archive. Instead, check out Chris Miller's information about the problem (now also only available on the Internet Archive) which includes a link to the patch tool that now has a permanent home at Embarcadero.
This is clearly something happening in the Delphi evaluator (which is part of the compiler). The odd thing is that if it is, in fact, going through writeobj.c, something is certainly not quite right. If you can reproduce this with a test case, please report it in QualityCentral (http://qc.embarcadero.com).
EEFFACE is the SEH exception code used by C++, which is "leaking" out to some Delphi code (in this case the IDE itself). When the exception code is not a Delphi generated exception or a hardware related exception, Delphi simply maps it to EExternalException.
This is not an exact answer but may help you with overcoming the error by describing my experience with it.
I received this error regularly when I went to Windows Vista and 7. The same code never received that error message on Windows XP. I could put a break point on the first line of the dpr file and found that it always seemed to occur when creating the splash screen to my applications. I tried various other ways to do splash screens but they always eventually resulted in getting an EEFFACE error when debugging.
So to overcome this issue, I now put
if DebugHook = 0 then
when I create and access the splash screen. The splash screen to my applications do not appear now when I'm debugging but at least I don't get that EEFFACE error anymore.
It seems that "External exception" isn't a Delphi's bug, I had this exception times ago and it was probably a problem with the motherboard, or with the hardware, because the program worked well at other machine.
Recently I've run into this and it's somehow related to the Delphi IDE. The following code ends up in this exception on the ShellExecute line:
url:='https://translate.google.com/#hu/en/%C3%A1';
ShellExecute(0,PChar('open'),PChar(url),nil,nil,SW_SHOWNORMAL);
But this is not:
url:='https://translate.google.com/#hu/en/%C3%A1';
ShowMessage(url);
ShellExecute(0,PChar('open'),PChar(url),nil,nil,SW_SHOWNORMAL);
But if I run my app outside of IDE everything is fine without the ShowMessage extra line. I don't know if it helps, but maybe in other cases where debugging is needed maybe this "trick" could help.
System: DELL Optiplex, intel Core2Duo, Win7 x64, Delphi 7
I've been struggling with EEFFACE for weeks. Finally found that the cause was this instruction:
PDFForgePDF.CopyPDFFile(pdffile,pdfcreatorfile,1,1);
the contents of variables pdffile and pdfcreatorfile were the same....
Maybe this can help some poor bugger like myself...
Related
Why autoextend on Oracle XE not worked
We had a problem with our prod environment. Suddenly the exception began to appear. ORA-01654: unable to extend index EMA.TRANSFERI2 by 128 in tablespace SYSTEM As the solution of the problem my collegue added new datafile. But the question is, why the autoextend mechanism didn't worked? I'm not DBA, but I checked the configuration and it seems ok to me. It occurs only on prod environment, so I would rather avoid experimenting. We have the table in system tablespace, which I already know, should be moved to users tablespace. But anyway, autoextend should work also on system tablepsace. Here is my config of table, datafiles and tablespace TABLESPACE_NAME | PCT_FREE | PCT_USED | INITIAL_EXTENT | NEXT_EXTENT | MIN_EXTENTS | MAX_EXTENTS | PCT_INCREASE SYSTEM | 10 | 40 | 65536 | 1048576 | 1 | 2147483645 | null FILE_NAME | FILE_ID | TABLESPACE_NAME | BYTES | BLOCKS | STATUS | RELATIVE_FNO | AUTOEXTENSIBLE | MAXBYTES | MAXBLOCKS | INCREMENT_BY | USER_BYTES | USER_BLOCKS | ONLINE_STATUS /u01/app/oracle/oradata/XE/system.dbf | 1 | SYSTEM | 629145600 | 76800 | AVAILABLE | 1 | YES | 629145600 | 76800 | 1280 | 628097024 | 76672 | SYSTEM /u01/app/oracle/oradata/XE/system2.dbf | 5 | SYSTEM | 1048576000 | 128000 | AVAILABLE | 5 | YES | 2147483648 | 262144 | 25600 | 1047527424 | 127872 | SYSTEM TABLESPACE_NAME | BLOCK_SIZE | INITIAL_EXTENT | NEXT_EXTENT | MIN_EXTENTS | MAX_EXTENTS | MAX_SIZE | PCT_INCREASE | MIN_EXTLEN | STATUS | CONTENTS | ALLOCATION_TYPE | SEGMENT_SPACE_MANAGEMENT | BIGFILE SYSTEM | 8192 | 65536 | null | 1 | 2147483645 | 2147483645 | 65536 | ONLINE | PERMANENT | LOCAL | SYSTEM | MANUAL | NO
The MAXBYTES value for your system.dbf file is set to 629145600, so when your file size reached that limit, it couldn't be extended any further. It had autoextended up to that point, but wouldn't extend beyond the soft limit that had been specified for the file. That was set when the tablespace was created, using the autoextend MAXSIZE clause. The limit may have been set because of the size of the underlying file system, to cause an error in case of runaway/unexpected growth, unintentionally, or for some other reason now known only to whoever set the database up. As an alternative to adding a second data file, your DBA could have increased the soft limit on the existing file with alter database. But neither should be done lightly; the reason for the original restriction should be understood (especially if the filesystem could run out of space as a result of an increase) and the reason for growth should be examined too.
How to create scrollview pagination with each page contain 4 image from plist/nsdictionary
I need to make an app that using a scrollview with pagecontrol to view image gallery, each page contains about 4 image and the image are loaded from plist or nsdictionary for example it will look like "WallpapersHD" in appstore. the example: ________ ________ ________ ________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |________| |________| |________| |________| ________ ________ ==SWIPE==> ________ | | | | | | | | | | | | | | | | | | | | | | | | |________| |________| |________| First Pge Second Page I really don't know how to start,, how to make the imageview have dependency with theimageurl data on plist file. As you can see in the first page there is a four imageview but in the second page there is only three imageview it because the data in plist is only seven imageurl.. so I need your help to do paging in ios
MGGridView is what you need. There's also an example app with the code Good luck
Heroku not listing pg_search_documents table
This is pretty weird but for some reason, heroku doesn't seem to show the pg_search_documents table when when I list tables using the heroku-sql-console. >> heroku sql SQL> show tables +------------------------+ | table_name | +------------------------+ | activity_notifications | | attachments | | businesses | | color_modes | | comments | | counties | | customer_employees | | customers | | delayed_jobs | | file_imports | | invitations | | invoices | | jobs | | paper_stocks | | paper_weights | | quotes | | rails_admin_histories | | schema_migrations | | tax_rates | | users | +------------------------+ As you can see, no mention of pg_search. Then, in the same session, SQL> select * from pg_search_documents; +---------------------------------------------------------------------------------------------------------------------+ | id | content | searchable_id | searchable_type | created_at | updated_at | +---------------------------------------------------------------------------------------------------------------------+ | 3 | Energy Centre | 3 | Customer | 2012-12-03 19:33:55 -0800 | 2012-12-03 19:33:55 -0800 | +---------------------------------------------------------------------------------------------------------------------+ It's also interesting that the show tables command lists only 20 tables whereas heroku pg:info says there are 21. The reason this is a problem rather than a curiosity is because I can't get heroku db:pull to pull down the pg_search_documents table (everything else pulls fine) and I can't test migrations on production data. I'm using PG Version: 9.1.6 on heroku and PostgreSQL 9.2.1 locally. Also PgSearch 0.5.7. Any ideas what the issue is?
Access violation while the program was idle - not trace information to track down the bug
I have a program that just popped up an AV. Until now the Eureka Log could find the source code line that generated the error but now it displays only this: Access violation at address 7E452E4E in module 'USER32.dll'. Read of address 00000015. Call Stack Information: -------------------------------------------------------------------------------------------- |Address |Module |Unit |Class|Procedure/Method |Line | -------------------------------------------------------------------------------------------- |Running Thread: ID=2640; Priority=0; Class=; [Main] | |------------------------------------------------------------------------------------------| |77F16A7E|GDI32.dll | | |IntersectClipRect | | |7E433000|USER32.dll | | |EditWndProc | | |7E42A993|USER32.dll | | |CallWindowProcA | | |7E42A97D|USER32.dll | | |CallWindowProcA | | |7E429011|USER32.dll | | |OffsetRect | | |7E4196C2|USER32.dll | | |DispatchMessageA | | |7E4196B8|USER32.dll | | |DispatchMessageA | | |00625E13|Amper.exe |Amper.DPR | | |76[16]| |7C915511|ntdll.dll | | |RtlFindActivationContextSectionString| | |7C915D61|ntdll.dll | | |RtlFindCharInUnicodeString | | |7C910466|ntdll.dll | | |RtlFreeUnicodeString | | |7C80B87C|kernel32.dll | | |IsDBCSLeadByte | | |7C9113ED|ntdll.dll | | |RtlDeleteCriticalSection | | |7C80EEF5|kernel32.dll | | |FindClose | | |7C901000|ntdll.dll | | |RtlEnterCriticalSection | | |7C912CFF|ntdll.dll | | |LdrLockLoaderLock | | |7C9010E0|ntdll.dll | | |RtlLeaveCriticalSection | | |7C912D19|ntdll.dll | | |LdrUnlockLoaderLock | | |7C9166C1|ntdll.dll | | |LdrGetDllHandleEx | | |7C9166B3|ntdll.dll | | |LdrGetDllHandle | | |7C9166A0|ntdll.dll | | |LdrGetDllHandle | | |7C912A8D|ntdll.dll | | |RtlUnicodeToMultiByteN | | |7C912C21|ntdll.dll | | |RtlUnicodeStringToAnsiString | | |7C901000|ntdll.dll | | |RtlEnterCriticalSection | | |7C912CC9|ntdll.dll | | |LdrLockLoaderLock | | |7C912CFF|ntdll.dll | | |LdrLockLoaderLock | | |7C9010E0|ntdll.dll | | |RtlLeaveCriticalSection | | |7C912D19|ntdll.dll | | |LdrUnlockLoaderLock | | |7C90CF78|ntdll.dll | | |ZwAllocateVirtualMemory | | |7C90CF6E|ntdll.dll | | |ZwAllocateVirtualMemory | | |7C9010E0|ntdll.dll | | |RtlLeaveCriticalSection | | |7C80BA57|kernel32.dll | | |VirtualQueryEx | | |7C80BA40|kernel32.dll | | |VirtualQueryEx | | |7C80BA81|kernel32.dll | | |VirtualQuery | | |7C901000|ntdll.dll | | |RtlEnterCriticalSection | | |7C912CC9|ntdll.dll | | |LdrLockLoaderLock | | |7C912CFF|ntdll.dll | | |LdrLockLoaderLock | | |7C9010E0|ntdll.dll | | |RtlLeaveCriticalSection | | -------------------------------------------------------------------------------------------- The program was totally idle while I got the error and its window was hidden by other windows. FastMM is active and set to full debug but it indicates no memory overwrite. Any hints about how to find the origin of this AV? Win XP, Delphi 7
I don't see an EditWndProc() method in user32.dll, but Delphi has a couple -- one dealing with combobox messages and one dealing with tree views. Given MS's comctrl mess, I'd guess you have a tree view? Check your tree view stuff. Given IntersectClipRect's parameters, it's easy to guess that it's being passed an invalid device context -- so...are you doing any custom painting for your tree view? If so, are you checking to make sure the canvas handle is ! NIL before you begin painting (try assertions if nothing else)?
I just wonder what's on line 76[16] in Amper.exe... That line number might be a hint of the location of the error. Then again, when it's just happening during an idle moment then it basically happens when the system is processing Windows messages like the mouse moving, keyboard events, timer updates and a lot more. It sometimes helps to search for the error message plus code. I've done a quick scan and found this KB from MS which suggests that this kind of error can happen when you call certain Windows API's with invalid parameters. But this KB doesn't apply to your error. Still, it gives you an idea about what to check: any Windows API call you make in your own code. Does it also generate this exception in the IDE, while you're debugging?
That's what EurekaLog does when it has nothing to work with. You need to rebuild and have the linker produce a detailed map file. That's how it knows what to apply its stack trace to.
External Exception EEFFACE in Delphi
While debugging my application with Delphi 2009, I sometimes get the following exception occurring: (source: beholdgenealogy.com) This only happens occasionally, but after pressing OK, then my IDE and program both may freeze. If I am lucky I can sometimes do a File/SaveAll in Delphi, but sometimes I can't. Either way I am stuck and then the only thing I can do is use Windows Task Manager to shut down Delphi. Of course, if I was unable to SaveAll, then I lose all the edits I had made since last saving. I have all the Delphi 2009 Updates installed right up to and including Update 4. I also have IDE Fix Pack 2009 2.9 installed. The Error is trapped for me by EurekaLog, and the error report gives the following call stack: Call Stack Information: ----------------------------------------------------------------------------------------------------------- |Address |Module |Unit |Class |Procedure/Method |Line | ----------------------------------------------------------------------------------------------------------- |Running Thread: ID=5068; Priority=0; Class=; [Main] | |---------------------------------------------------------------------------------------------------------| |205669C6|dbkdebugide120.bpl |Debug.pas |TDebugger |DBKWndProc |11598[6] | |777DE49A|ntdll.dll | | |KiUserExceptionDispatcher | | |7705E0CB|kernel32.dll | | |RaiseException | | |03E8E3E8|dcc120.dll |WRITEOBJ.OBJ | |C62_0 | | |03E3066D|dcc120.dll |SYMTAB.OBJ | |MakeOverloadedPropertyList| | |03E3064C|dcc120.dll |SYMTAB.OBJ | |MakeOverloadedPropertyList| | |03E30D76|dcc120.dll |SYMTAB.OBJ | |EnterMethod | | |03E30D6C|dcc120.dll |SYMTAB.OBJ | |FindBaseClassMethod | | |03DE8D30|dcc120.dll |DECL.OBJ | |PatchConstRecordParameter | | |777DE590|ntdll.dll | | |RtlLeaveCriticalSection | | |03DBBF70|dcc120.dll |BROWCMGR.OBJ | |PutToAddress | | |03DBC436|dcc120.dll |BROWCMGR.OBJ | |GetNearestSymName | | |777DE550|ntdll.dll | | |RtlEnterCriticalSection | | |219C5BDA|win32debugide120.bpl|Win32Debug.pas |TWin32LinkUnit |GetCppDebugHook |1923[3] | |219C5BB8|win32debugide120.bpl|Win32Debug.pas |TWin32LinkUnit |GetCppDebugHook |1920[0] | |219C644E|win32debugide120.bpl|Win32Debug.pas |TWin32Process |DoLinkUnitCreated |2198[10] | |50001CE4|rtl120.bpl |System.pas | |InterlockedIncrement |3200[0] | |5000CD59|rtl120.bpl |System.pas |TInterfacedObject |_AddRef |21759[1] | |2055F40F|dbkdebugide120.bpl |Debug.pas |TProcess |LinkUnitCreated |8454[1] | |2055F408|dbkdebugide120.bpl |Debug.pas |TProcess |LinkUnitCreated |8453[0] | |2055CEC7|dbkdebugide120.bpl |Debug.pas |TEvaluatorCallback|ntfyLinkUnitDelta |7167[7] | |77050DF0|kernel32.dll | | |VirtualProtect | | |50003FE4|rtl120.bpl |System.pas | |_ReallocMem |3512[0] | |500093F6|rtl120.bpl |System.pas | |_LStrSetLength |15889[38]| |50004508|rtl120.bpl |System.pas | |Move |4414[0] | |5001DDB9|rtl120.bpl |SysUtils.pas | |StrLCopy |7852[5] | |5007E559|rtl120.bpl |UxTheme.pas | |DrawThemeTextEx |5226[2] | |5007E524|rtl120.bpl |UxTheme.pas | |DrawThemeTextEx |5224[0] | |2110A98D|vclactnband120.bpl |ThemedActnCtrls.pas|TThemedMenuButton |DoDrawText |488[23] | |50009E88|rtl120.bpl |System.pas | |_UStrClr |16961[0] | |2110A9A2|vclactnband120.bpl |ThemedActnCtrls.pas|TThemedMenuButton |DoDrawText |490[25] | |75FC7BFE|USER32.dll | | |CallNextHookEx | | |20AA9C5E|designide120.bpl |DeskUtil.pas | |SetFocusHook |435[4] | |210E8B83|vclactnband120.bpl |ActnMenus.pas | |CallWindowHook |741[20] | |50057F7D|rtl120.bpl |Classes.pas |TComponent |UpdateAction |11881[1] | |50006EE4|rtl120.bpl |System.pas | |_CallDynaInst |10209[0] | |501EA802|vcl120.bpl |Forms.pas | |ProcessUpdate |6739[1] | |50006F3C|rtl120.bpl |System.pas |TObject |InheritsFrom |10281[0] | |50006E1A|rtl120.bpl |System.pas | |_IsClass |10107[1] | |50006E0C|rtl120.bpl |System.pas | |_IsClass |10106[0] | |501EA870|vcl120.bpl |Forms.pas | |TraverseClients3 |6756[5] | |501EA818|vcl120.bpl |Forms.pas | |TraverseClients3 |6751[0] | |501EA88A|vcl120.bpl |Forms.pas | |TraverseClients3 |6756[5] | |50047748|rtl120.bpl |Classes.pas |TList |Get |3366[0] | |501C865E|vcl120.bpl |Controls.pas |TWinControl |GetControl |8473[4] | |50006F3C|rtl120.bpl |System.pas |TObject |InheritsFrom |10281[0] | |50006E1A|rtl120.bpl |System.pas | |_IsClass |10107[1] | |501C8668|vcl120.bpl |Controls.pas |TWinControl |GetControlCount |8478[0] | |501EA87B|vcl120.bpl |Forms.pas | |TraverseClients3 |6756[5] | |501EA818|vcl120.bpl |Forms.pas | |TraverseClients3 |6751[0] | |501EA8E2|vcl120.bpl |Forms.pas |TCustomForm |CMActionUpdate |6778[11] | |501C565A|vcl120.bpl |Controls.pas |TControl |WndProc |6642[91] | |501C5388|vcl120.bpl |Controls.pas |TControl |WndProc |6551[0] | |501C9CE7|vcl120.bpl |Controls.pas |TWinControl |WndProc |9336[136]| |75FC7C2B|USER32.dll | | |CallNextHookEx | | |75FCC477|USER32.dll | | |InvalidateRect | | |75FCC41E|USER32.dll | | |InvalidateRect | | |75FCC49D|USER32.dll | | |CallWindowProcW | | |75FCC487|USER32.dll | | |CallWindowProcW | | |205669A5|dbkdebugide120.bpl |Debug.pas |TDebugger |DBKWndProc |11595[3] | |500591DC|rtl120.bpl |Classes.pas | |StdWndProc |12703[8] | |75FC9467|USER32.dll | | |IsWindowVisible | | |75FC8B0B|USER32.dll | | |DispatchMessageW | | |75FC8B01|USER32.dll | | |DispatchMessageW | | |501EEABD|vcl120.bpl |Forms.pas |TApplication |ProcessMessage |9660[30] | |501EE9A0|vcl120.bpl |Forms.pas |TApplication |ProcessMessage |9630[0] | |501EEB02|vcl120.bpl |Forms.pas |TApplication |HandleMessage |9690[1] | |501EEAF8|vcl120.bpl |Forms.pas |TApplication |HandleMessage |9689[0] | |501EEE2D|vcl120.bpl |Forms.pas |TApplication |Run |9827[26] | |501EED64|vcl120.bpl |Forms.pas |TApplication |Run |9801[0] | |004259E6|bds.exe |bds.dpr | |bds |198[8] | |770CECC9|kernel32.dll | | |BaseThreadInitThunk | | ----------------------------------------------------------------------------------------------------------- As you can see, all of the call stack is in Delphi and Windows. It does not connect back at all to any line in my program. I have looked at the webpage: External Exception EEFFACE and translated it from German to English, but it appears to be talking about Delphi C++ whereas I don't use C++ at all. My problem is I have no idea what might be causing this as it does not happen consistently. I have no idea even where to look to find it or how to track it down. Does someone know what this is and how I can track it down or at least prevent it from happening? Alex of EurekaLog posted this in response to my query on their forum: I think it may be a bug in Delphi's debugger. Possibly related to evaluation tooltips or something similar. See for yourself - we have an C++ exception in system module (EEFFACE is a special code for VCL exception. When VCL encounters an unknown C++ exception - it wraps it into EExternalException object with code = EEFFACE) and call stack includes Delphi debugger's units: |205669C6|dbkdebugide120.bpl |Debug.pas |TDebugger |DBKWndProc |11598[6] | |7705E0CB|kernel32.dll | | |RaiseException | | |03E8E3E8|dcc120.dll |WRITEOBJ.OBJ | |C62_0 | | |03E3066D|dcc120.dll |SYMTAB.OBJ | |MakeOverloadedPropertyList| | |03E3064C|dcc120.dll |SYMTAB.OBJ | |MakeOverloadedPropertyList| | |03E30D76|dcc120.dll |SYMTAB.OBJ | |EnterMethod | | |03E30D6C|dcc120.dll |SYMTAB.OBJ | |FindBaseClassMethod | | |03DE8D30|dcc120.dll |DECL.OBJ | |PatchConstRecordParameter | | |03DBBF70|dcc120.dll |BROWCMGR.OBJ | |PutToAddress | | |03DBC436|dcc120.dll |BROWCMGR.OBJ | |GetNearestSymName | | |219C5BDA|win32debugide120.bpl|Win32Debug.pas |TWin32LinkUnit |GetCppDebugHook |1923[3] | |219C5BB8|win32debugide120.bpl|Win32Debug.pas |TWin32LinkUnit |GetCppDebugHook |1920[0] | |219C644E|win32debugide120.bpl|Win32Debug.pas |TWin32Process |DoLinkUnitCreated |2198[10] | |50001CE4|rtl120.bpl |System.pas | |InterlockedIncrement |3200[0] | |5000CD59|rtl120.bpl |System.pas |TInterfacedObject |_AddRef |21759[1] | |2055F40F|dbkdebugide120.bpl |Debug.pas |TProcess |LinkUnitCreated |8454[1] | |2055F408|dbkdebugide120.bpl |Debug.pas |TProcess |LinkUnitCreated |8453[0] | |2055CEC7|dbkdebugide120.bpl |Debug.pas |TEvaluatorCallback|ntfyLinkUnitDelta |7167[7] | I think that you should post this description to Embarcadero's Quality Central. Try to disable "IDE integration" check-box (it's located in IDE's "EurekaLog"/"EurekaLog IDE Options" menu) and run your application - see if there will be a change in behavior. I have now submitted a report to Quality Central at: http://qc.embarcadero.com/wc/qcmain.aspx?d=81881 Hopefully with this information, Embarcadero will be able to prevent this in future releases. I come back to this question over 4 years later, and realize that a few months ago, I found the solution, so I am posting it here for anyone else who may encounter this. The problem and solution were provided in Olaf Monien's blog, in a post from 2009/07/22 titled Delphi 2009 / Windows 7 / 64 bit Debugger Crash Workaround. Olaf's instructions on that post worked perfectly for me, and the problem is gone. I thanked him in a comment on his blog post. As #rossmcm points out in his comment, Olaf's blog post is no longer there, but the post can still be found on the Internet Archive. Instead, check out Chris Miller's information about the problem (now also only available on the Internet Archive) which includes a link to the patch tool that now has a permanent home at Embarcadero.
This is clearly something happening in the Delphi evaluator (which is part of the compiler). The odd thing is that if it is, in fact, going through writeobj.c, something is certainly not quite right. If you can reproduce this with a test case, please report it in QualityCentral (http://qc.embarcadero.com). EEFFACE is the SEH exception code used by C++, which is "leaking" out to some Delphi code (in this case the IDE itself). When the exception code is not a Delphi generated exception or a hardware related exception, Delphi simply maps it to EExternalException.
This is not an exact answer but may help you with overcoming the error by describing my experience with it. I received this error regularly when I went to Windows Vista and 7. The same code never received that error message on Windows XP. I could put a break point on the first line of the dpr file and found that it always seemed to occur when creating the splash screen to my applications. I tried various other ways to do splash screens but they always eventually resulted in getting an EEFFACE error when debugging. So to overcome this issue, I now put if DebugHook = 0 then when I create and access the splash screen. The splash screen to my applications do not appear now when I'm debugging but at least I don't get that EEFFACE error anymore.
It seems that "External exception" isn't a Delphi's bug, I had this exception times ago and it was probably a problem with the motherboard, or with the hardware, because the program worked well at other machine.
Recently I've run into this and it's somehow related to the Delphi IDE. The following code ends up in this exception on the ShellExecute line:
url:='https://translate.google.com/#hu/en/%C3%A1';
ShellExecute(0,PChar('open'),PChar(url),nil,nil,SW_SHOWNORMAL);
But this is not:
url:='https://translate.google.com/#hu/en/%C3%A1';
ShowMessage(url);
ShellExecute(0,PChar('open'),PChar(url),nil,nil,SW_SHOWNORMAL);
But if I run my app outside of IDE everything is fine without the ShowMessage extra line. I don't know if it helps, but maybe in other cases where debugging is needed maybe this "trick" could help.
System: DELL Optiplex, intel Core2Duo, Win7 x64, Delphi 7
I've been struggling with EEFFACE for weeks. Finally found that the cause was this instruction: PDFForgePDF.CopyPDFFile(pdffile,pdfcreatorfile,1,1); the contents of variables pdffile and pdfcreatorfile were the same.... Maybe this can help some poor bugger like myself...