Delphi bug: Exception EAccessViolation in module rtl210.bpl at 00016A9C [SOLVED]

I keep getting this error at Delphi shut down:

Application Error - Exception EAccessViolation in module rtl210.bpl at 00016A9C.
Access violation at address 50066A9C in module 'rtl210.bpl'. Read of address 06152AF8.

Solution 1:

The problem is fixed by restoring this registry key to its original state: [HKEY_CURRENT_USER\Software\Embarcadero\BDS\15.0\Known IDE Packages]

Here is the pristine value for this key:

[HKEY_CURRENT_USER\Software\Embarcadero\BDS\15.0\Known IDE Packages]
"$(BDS)\\bin\\htmide210.bpl"="(Untitled)"
"$(BDS)\\bin\\comptoolbar210.bpl"="Component Toolbar Package"
"$(BDS)\\bin\\mlcc210.bpl"="(Untitled)"
"$(BDS)\\Bin\\tgide210.bpl"="(Untitled)"
"$(BDS)\\Bin\\delphiosx32210.bpl"="Delphi OSX32 Platform"
"$(BDS)\\Bin\\macosxdebugide210.bpl"="MacOS"
"$(BDS)\\Bin\\delphiwin64210.bpl"="Delphi Win64 Platform"
"$(BDS)\\Bin\\win64debugide210.bpl"="(Untitled)"
"$(BDS)\\Bin\\GuidedTour210.bpl"="Embarcadero Guided Tour Package"
"$(BDS)\\Bin\\ModernTheme210.bpl"="(Untitled)"
"$(BDS)\\Bin\\asmview210.bpl"="Assembly Browser Package"
"$(BDS)\\Bin\\dbkdebugide210.bpl"="(Untitled)"
"$(BDS)\\Bin\\delphiwin32210.bpl"="Delphi Win32 Platform"
"$(BDS)\\Bin\\dotnetcoreide210.bpl"=".NET Core IDE Package"
"$(BDS)\\bin\\exceptiondiag210.bpl"="(Untitled)"
"$(BDS)\\bin\\fileexplorer210.bpl"="(Untitled)"
"$(BDS)\\bin\\historyide210.bpl"="(Untitled)"
"$(BDS)\\Bin\\htmlhelp2210.bpl"="HtmlHelp Viewer"
"$(BDS)\\bin\\idefilefilters210.bpl"="IDE File filters"
"$(BDS)\\bin\\plugview210.bpl"="Pluggable Tree View Package"
"$(BDS)\\Bin\\projpageide210.bpl"="Value Data: Project and template library package"
"$(BDS)\\Bin\\startpageide210.bpl"="Start Page IDE Package"
"$(BDS)\\Bin\\tlbview210.bpl"="TypeLibrary Browser Package"
"$(BDS)\\Bin\\codetemplates210.bpl"="(Untitled)"
"$(BDS)\\bin\\coreproide210.bpl"="Core IDE Pro Package"
"$(BDS)\\bin\\dbkdebugproide210.bpl"="(Untitled)"
"$(BDS)\\Bin\\profiledeployide210.bpl"="(Untitled)"
"$(BDS)\\Bin\\profilemgride210.bpl"="(Untitled)"
"$(BDS)\\Bin\\sdkmgride210.bpl"="Embarcadero SDK Manager"
"$(BDS)\\bin\\refactoride210.bpl"="Core Refactoring Package"
"$(BDS)\\bin\\todoide210.bpl"="ToDo"
"$(BDS)\\Bin\\comcore210.bpl"="HtmlHelp Viewer"
"$(BDS)\\Bin\\projecttargets210.bpl"="(Untitled)"
"$(BDS)\\Bin\\vclmenudesigner210.bpl"=".NET Core IDE Package"
"$(BDS)\\Bin\\DataExplorerIDE210.bpl"="(Untitled)"
"$(BDS)\\Bin\\unittestide210.bpl"="(Untitled)"
"$(BDS)\\Bin\\iteidew32210.bpl"="(Untitled)"
"$(BDS)\\Bin\\VisualizationServiceIDE210.bpl"="Visualization IDE Service Package"
"C:\\Users\\Public\\Documents\\Embarcadero\\Studio\\15.0\\Experts\\IDEFixPackStartup.bpl"="IDE Fix Pack Startup"


[UPDATE]
SOLUTION 2 (and cause):

After some work I discovered what caused this: The 'FMX controls' package was disabled (probably I disabled it since FMX is still infantile and I don't intend to use it right now). Re-enabling this package solved the problem.

Also removing "$(BDS)\\Bin\\delphiwin32210.bpl"="Delphi Win32 Platform" helped.

Delphi: Access violation in module 'bindcomp210.bpl'

I keep getting an "Access violation at address 1204F872 in module 'bindcomp210.bpl'. Read of address 1423C764" message during Delphi startup.

After poking around I have found the solution: delete the
"Project" and/or "SaveFileDirectory" keys in [HKEY_CURRENT_USER\Software\Embarcadero\BDS\15.0\Session]

How to solve the "Cannot load a form that has itself as ancestor" error in Delphi

How to solve the "Cannot load a form that has itself as ancestor" error in Delphi

This is how a new/empty project should look like:

uses
  Forms,
  Unit1 in 'Unit1.pas' {Form1};

And this how your project probably looks like:

uses
  Forms,
  Unit1 in 'Unit1.pas' {Form};    <--------- here="" missing="" span="">

I spent on hour to find the well hidden culprit.
I had a previous problems where Delphi messed up the DPR file (the {$R *.res} declaration).
When do we ever learn?

How to make GDrive synchronize faster?

You are in the  middle of your work and for some reason you need to restart the computer. It restarts fast BUT you cannot start your work (if you are working in team with others) because your Google Drive takes a good long fucking nice nap before it synchronizes all the files.
So you delete some of those 500MB files hoping that it will synchronize faster. But it won't!

I did some research and I have found out that the size of the files you have in drive doesn't matter too much. What matters is the number of files. So, 5000 files of 0.1MB will take way much longer to synchronize than a singe 500MB files even if the total amount of data (5000 * 0.1MB = 500MB) is the same.

So, start compressing the folders that contains LOTS of (small) files if you don't use them right now. If the compression takes too long you can set your compressor to 0 compression (this is called a 'tar ball' or 'compacting'). This will generate a single files, of the same size as the initial uncompressed data. So you don't gain something, space-wise, BUT ITS ONLY ONE, not 5000! And now we know that one big file synchronizes faster than 5000 tiny files!

PS: 
1. Don't use the 'Compress contents to save disk space' feature located in the Properties windows that appears when you right-click a folder. It won't work.   
2. Don't be a lamer. Use RAR instead of ZIP. Arcive created with RAR are MUCH smaller (better) than the ones created with ZIP. And if you activate the 'Create solid archive' in WinRar the archive will be even smaller!




Enjoy your new GDrive speed. 
Don't forget to leave a comment...


____

Related posts: Google drive still unreliable

Google Drive still unreliable (How to fix 'Primary key must be unique' error)

I hate Google Drive. It is haunted by too many bugs. 

Recently my GDrive application started showing a "primary key must be unique" error message, asking me to disconnect the drive and start all over again. I did that. Took few hours to resynchronize it all. But the next day I got the same error and asked me again to repeat the operation. I have been poking the forums (including Google's forum) up and down for months and found no real solution. So I had to do the job on my own. This is how to fix the "primary key must be unique" error:

1. Start Google Drive
2. Hold the SHIFT key pressed while clicking the Google Drive systray icon. This will show the 'Enable diagnostic mode' special menu.
3. Click 'Enable diagnostic mode' menu.
4. Wait until Google Drive crashes and shows the "primary key must be unique"error message. Let the application shutdown.
5. Go to "c:\Users\YOUR_USER_NAME\AppData\Local\Google\Drive" folder and open "sync_log.log".
   Note: Replace 'YOUR_USER_NAME' with your Windows account name (the account in which you are logged in). You can see this name when you press the 'Start' button.
6. Look up this text: "Detected conflict while trying to download file to".
7. After 'to' follows the name of the file that generated the conflict. Locate that file and delete it or (better) rename it. Do this for all conflicted files (if there are more than one).
8. Restart Google Drive.
   That's it.

This technique can be used to debug other Google Drive errors also.


Update 1 - How to do it on Mac OS (thanks to Maik):

Thanks, this fix also works for Apple Mac OS-X.
To get to the log file:
- in finder click the Go menu
- with the menu open click ALT-key so the hidden Library item appears
- open the Library and go to folder Google -> Drive


Update 2 - More GDrive bugs: The trash cannot be purged

Now my Google Drive account shows that is 95% full even if I don't have many files loaded in GDrive (I have a total of 1.1GB). After investigation I have discovered that are files locked in the 'Trash' that cannot be deleted. I contacted Google Drive support and they said they will fix my account. The provided additional Google Drive space so I can keep using my GDrive until they will fix the problem. That was in February 2012. Still no word from them.


Update 3 - How to make GDrive synchronize faster?



Related
How to improve the Google Drive synchronize speed?

_______________


With this occasion I want to thanks Google team for the fucking 'good' job they did and to tell them: I don't believe in witches, but they surely exist. 

 

Delphi 2007 - (bad) Review

Delphi 2007 - Same old stuff under a new hat?

We all love Delphi. It is smart, easy to understand, really fast and user friendly.

But is the IDE the one that makes is so nice or the language?

Every time Borland released a new version forced as to go through a painful learning and re-adaptation process. But not because of the language but because of the buggy IDE.

You can't argue with me: there are HUGE lists of unresolved bugs for every possible version released.

It is the same for Delphi 2007? Let’s find out. I just installed Delphi 2007 on my computer. First time I was really glad to have it because people ware speaking nice about this new version.

After the first attempt to install it failed, I tried again and I somehow succeed.

Until now I can report more bad stuff that good ones. Anyway I am still happy that I can report also good stuff.

Compared with Delphi 2005, Delphi 2007 is a charm. Compared with Delphi 2006 it is a little bit better. Compared with Delphi 7 it is worst.

* I thought that Delphi 2007 is free of .Net. Well that was a lie. Delphi 2007 refuses to install without .Net 2.0 (and other craps like this).

* The first bug I saw few minutes after I open the IDE for the first time was the fast blinking icons in the tool bar. I had the same problem with Delphi 2005 and 2006.

* The next bug, this time a really big one was the help system which in 30% is working. Imagine yourself what is with the rest of 70%.

The help system is a disaster. It takes much more time to load than Delphi itself. If you ask help for an instruction/window on IDE it always answers: 'Error. No help found for 2029. OK | Details'.

When it does not display that stupid answer then it returns allot of garbage from MS .Net and MS API help. In most cases the right answer is not there.

For example after pressing F1 for while the cursor was on the reserved word 'Function', the help system returned (after 37 seconds!).

Conclusions?

* Sometimes the cursor has the same color as the IDE background. You can have big fun trying to figure out where is your cursor on the screen. The solution is to restart the IDE and pray to work. If not, restart again (and pray harder).

* Delphi 2007 takes a lot of time to load to memory (my system is AMD 64 x2 4.6GHz and 1GB DDR2 at 800MHz). The average amount of memory for small projects is 50-120MB. But sometimes if goes to 600-1000MB.

So you need at least 2GB or RAM to work with this version of Delphi.

* Other small problems can be observed in IDE. Many windows behave strange or you have no buttons to configure them. For example if you have error when you compile a program, the 'Messages' will pop-up at the bottom of the IDE. This is ok. Right? But after you fix the problem the window does not close itself as in Delphi 7. So every time you compile a program you need to go and manually close that window.

* The undo system is also a disaster. Sometimes is working, sometimes (most of the cases) is not. So if you made a mistake you can't undo it so you need to rewrite all that code.

I don't think that Delphi 2007 is better than Delphi 7. Actually it is a disaster. Not as big as Delphi 2005 but still a disaster. I hope that Borland (hic, CodeGear) will release a patch (or more) really soon, but until then Delphi 2007 can't be used.

I didn't post here every small bug I have found, but only the big ones. I will update this entry as I will find out more.

Now I am supposed to speak also about the good parts of Delphi 2007. Well until I will have the patch to be able to run Delphi 2007 form more than 1 hour, I will post also the nice parts of Delphi 2007, until then I will stick with Delphi 7 and with its already known bugs (and work around).

Please drop me a line if you know how to make the help system to work and how to remove the useless (MS API) results from a search.