Davide Angeli

Same here. Yesterday LSP/Codecompletion doesn't work the whole morning (close/reopen ide multiple times, rebuild every library etc but nothing) then I closed a couple of source files in the IDE's editor and it start to work again! Another amenity of yesterday, debugging a 64bit delphi application the IDE consumed all my PC memory (8Gb on 16Gb used by the ide alone!). This obviously crashed the whole system making debugging impossible. Closed the IDE and redone the operation everything worked regularly. They are not insurmountable problems but they are very annoying because they are continuous.

After several days of working with the 3 patches applied I have to say that things are going better but 10.4.2 is still far to be a stable environment to work (in my configuration). Even if with less frequency I continue to have scattered errors in the IDE: - access violations in dcc32270.dll (usually compiling a project not active and always need to close/kill ide when happen because of cascade of access violations) - access violations in rtl270.bpl (switching between projects / closing the ide) - "Error reading Image1.Picture.Data" doing text search in ide editor I think/hope that embd should/could invest some time to make things better for those who work with project groups and runtime packages.

After a day of testing the update I make some considerations on the subject of this conversation: the internal error situation has definitely improved. Now in my case I have a more stable situation again. Let's say that in my opinion this bug has exacerbated the underlying problems that exist in the management of Delphi project groups. I always work with an open group of projects and sometimes it happens, despite being positioned on a project, to compile another one (for example a dll used by the active project); I do it with the right click selecting the project in the project window. In this case, despite the patch, it has already happened to me a couple of times that the IDE went into error (an access violetion in dcc32270.dll) and then if I return to compile the active project I get the internal error in question again. However these now seem sporadic cases probably linked to internal problems in switching on the fly from one project to another.

I raccomend this too because in the first time I tryed to apply te patch I selected YES and one of the patches was not applied. After strange errors (red text in cmd prompt) I read the patch logs and I discovered the the second patch did nothing but both of them result installed in the getit manager. So I unistalled both e reinstalled both selecting "NO" when getit ask me to close the IDE. Now I did the same with the third patch. This way of applying patches via getit is terrible but after few attempts I got the job done... I raccomend also to pay attention to UAC prompt that in my case does not appear on top: I was waiting to the patch apply and because it tooks tool long (cmd window opened doing nothing) I noticed on the task bar the flashing icon of the UAC prompt.

I completely agree. I can't understand why I have to change my infrastructure (used for decades) just because Embd broke the toy ... For a thousand reasons that I am not going to list I absolutely do not want to have a mega gigantic single exe. After all, how is Delphi made? Isn't it an exe that makes extensive use of dll bpl files? It would be like telling someone who wants to use Ms Word not to use docx files use only plain text files because docx do not work and crash the program! If creating programs that run bpl and dll is not a recommended practice, Embd has to declare it out of the product box!

Excuse me but I'm just curious to understand in which kind of situations the IDE fails like in mine... Which kind of projects are you working on? A singole exe file? My main projects have all a structure of a main exe, 3/4 runtime packages (common to every project) and several dll's. I'm daily working with project groups. Every piece (exe, bpl, dll could be compile in 32 or 64 bit).

I've only projects that use packages... Top priority correction for me is an hot fix released in a couple of days not one released in more than a couple of months!

I am baffled and pissed, here time flies and still no answer or solution from Embarcadero! I cannot understand why they are not giving top priority to correct these problems. It's unbelievable ... Daily work in these conditions is a nightmare! But is there anyone using 10.4.2 without problems? Has anyone switched to this shameful bug-ridden version to work seriously? Am I the only fool?

Same for me. It is why I discarded the idea of using MSBuild to solve the problem. I absolutly need a full functioning debugger to work. We need Embarcadero fix ASAP!!!

It would be nice as you can see here, almost a month ago, I gave my full availability also for remote assistance if necessary but no one took me into consideration...

Yes it would be nice... I'm locked because in my case the internal error is systematic at every new compile. In the next few days I have to decide if I can continue with 10.4.2 or if I have to switch back to 10.4.1. I've wasted a lot of precious time with this issue and my boss is not really happy... In my situation with 10.4.2 the dailywork is a real bloodbath. I think the worst release ever in terms of productivity. I really love Delphi (I'm using Delphi since release 1!) but it is not acceptable to wait months to have fixed bugs of this magnitude.

"Failed to load ssleay32.dll" I did a file search on my develop system just now and I could see dozens of OpenSSL versions on it ... I suppose that some of it is loaded before the one that I want, so I forceed the path with IdOpenSSLSetLibPath(mypath) and now it works fine without errors. Just for knowledge, after search I could see that libeay32.dll+ssleay32.dll are present also in "c:\Program Files (x86)\Embarcadero\Studio\21.0\bin\subversion\" even if this release is not the last "1.0.2u" but it is the "1.0.2n". Yes it work Thank you

Hi, I'm trying to use the latest Open SSL available on GitHub (1.0.2u) and using it with Indy included in 10.4.2 but I get always an exception that Indy "Could not open SSL library". I'm using it on a SMTP connection. Before the exception I get a messagebox with the message that is impossible to find the ordinal 4684 in the ssleay32.dll... Is this (1.0.2u) the right DLL to use with Delphi 10.4.2? Thanks

I have opened the QC to create a new report but I see that someone has already done so: https://quality.embarcadero.com/browse/RSP-33425 Hope this could be solved quickly because it is really impossible to work in this way.

Hi, after several test I've tryed also this one and I could see that this kind of internal error is an access violation in BDS.EXE: First chance exception at $08343340. Exception class $C0000005 with message 'access violation at 0x08343340: read of address 0x00000018'. Process bds.exe (12984) Analizing the "Modules" window I see that that address refers to dcc32270.dll. I've attached a screen shot. Is this one helpfull for someone to discover the problem? I'm not capable to analize further.

Same here... the last week I've dedicated almost my time to found a workaround but I'm still fighting. Now I'm trying to reorganize and simplify the structure of my program and doing some cleanup as @FredSsuggested, to see if things get better.

It's hard... the project is quite complex with several runtime packages

I agree... Just cleaned up the system: manual Delphi uninstall + registry cleaned + delete all embarcadero files on system + all bpl, dcp, dcu... Fresh install from web installer this time (last one was from ISO). Installed only the Windows platform (no linux, no android, no ios etc) Installed only third parts components needed by my projects For now not installed expertes/toolas (MMX, GExpert etc) THE PROBLEM STILL PERSISTS! I think that these random errors could be related to same bug: sometimes "Access violation at address 0BAF903E in module 'dcc32270.dll'. Read of address A2DCF46C." sometimes in place of the internal error F2084, I get this: "[dcc32 Fatal Error] aaaaa.pas(27): E2411 Unit bbbbb in package cccccc refers to unit ddddd which is not found in any package. Packaged units must refer only to packaged units" often I get also "Access violation at address 50060148 in module "rtl270.bpl". Read of address 3C49FAC4" I don't know what to do at this point... I'll open a ticket on QC, but honestly, not being able to reproduce the case in a small test project, I doubt it will be considered.

Usefull this tool. I found and correct some minor red entries but unfortunatly this doesn't help. I'll try with cleanregistry and then a clean reinstall hoping to solve this annoying situation.

Just to summarize after several tests, checking configurations, library paths, dcu, dcp etc. now I'm in this situation (after a clean computer restart): Open IDE Open a Project group Compile and run the active project Do something with the app Close the app and come back to IDE Compile again = "F2084 Internal Error: AV0C793340(0BA770000)-R00000018-0" For me this is sistematic. Workarounds that I found for this (working in my situation I mean): close/reopen the project then I could compile/run again the app (rarely I've to restart IDE) open "Tools\options" and change something in "Language\Delphi\Library" variable "Library path": it's enough to move up a path + save + close the options, open again the library path to restore the previous position (move down) and save; doing these operations the internal error vanished. I suppose that saving that kind of parameter (even it is not modified at last) force some "refresh/initialization" in the IDE compiler environment that solves the issue (as reopen project did) Set the "Project Options" \ "Delphi Compiler" \ "Use MSBuild externally to compile" (setting also "Include remote debug symbols" in "Linking" page ). This not lead to internal errors but I'm having several problems with debugging (always get the cpu window on breakpoints and unable to step in the source code). I don't know if this info could help someone to reach/guess why this error happen. I would like to report this in QC but I'm not able to reproduce in a small case so therefore it would become one of the many reported errors that would never be corrected...

I Installed Delphi 10.4.1 over 10.4 similar to 10.4.2 (automatic unistallation during the installation). 10.4, 10.4.1, 10.4.2 all installed via ISO image. "Enable unit directory cache" is enabled by default in my configuration (never set that check). I'll get a chanche at the "See also" section. It's a nightmare here: after every compile + run + debug I need to close/reopen project or close/reopen IDE. I am wasting a lot of precious time and so I'm considering switch back to 10.4.1. Before doing that I think that the last attempts will be ProcMemAllocLimit and then uninstall every thing, cleaning the machine and reinstall 10.4.2 as fresh installation....

My memory situation is this when I get the problem:

Just unistalled all the experts but the problem still remains.

These steps are the same for me. If I perform those operations I get the problem systematically.

Hi, before posting here I tried the suggestions from the first link and I must say that things seem to be better. MSBuild is an "unexplored world" for me and since I have not been able to activate debugging after that type of compilation, before taking this path I wanted to understand if there was any hope of solving the problem without changing the way of operating that has been going on for more than 20 years. Honestly I had also read the indications of the second link, but as someone else has already written, I strongly doubt that the problem lies in how the code is written since the solution is always to close and reopen the project to make the compiler work. This clearly indicates an internal problem with the IDE probably the excessive memory consumption at compile time as suggested in first link.