Current filter:
                                You should refresh the page.
                                  • To start with, we looked at B146004, which seemed to be an identical problem, and ran the supplied dxTest_B146004.exe, but that had no problems and did not hang.

                                    Our ActiveX Library has several VCL forms containing a number of DevExpress components, and are the same forms that we use in the EXE version of our application. The DLL allows third party developers to use particular exposed functionality available in the main application in their own developments.

                                    Several of these forms have TcxTreeLists and also have a TdxComponentPrinter included so that the trees can be printed as they appear on the screen.

                                    After much trial and error, we have identified that one of the units added to a VCL form when a TdxComponentPrinter is included causes the ActiveX DLL to hang when trying to register using REGSVR32, but only on a very select number of computers; one in-house and two known of at client sites. This is out of an installation pool of over fifty machines.

                                    The hang occurs on these same machines whether we built the DLL using Delphi 7 and ExpressPrinting System 2011 1.7, or Delphi XE2 and ExpressPrinting System 2011 2.6.

                                    We created a version of the ActiveX Library where all TdxComponentPrinters were removed, and any related unit in the Use clauses were removed. This version successfully registers with Regsvr32 (from an elevated command prompt, of course) without hanging.

                                    We then added a single TdxComponentPrinter to one of the forms, and upon saving, the following units were added to the Use clause:

                                    dxPSGlbl, dxPSUtl, dxPSEngn, dxPrnPg, dxBkgnd, dxWrap, dxPrnDev, dxPSCompsProvider, dxPSFillPatterns, dxPSEdgePatterns,   dxPSPDFExportCore, dxPSPDFExport, cxDrawTextUtils, dxPSPrVwStd, dxPSPrVwAdv, dxPSPrVwRibbon, dxPScxPageControlProducer, dxPScxEditorProducers, dxPScxExtEditorProducers, dxPSCore.

                                    So we created a new ActiveX Library with a single interface and CoClass, with a single method that would display the FormMain included in dxTest_B146004. This also successfully registered.

                                    But as soon as we added the dxPUtl unit mentioned in B146004 to the form from the B146004 sample, the DLL hangs Regsvr32, so we're pretty certain that something in that unit is causing problems, both in version 59 from 2010, and version 2011 1.7 and 2011 2.6.

                                    Do you have any suggestions on how we can track down what is going wrong inside dxPUtl?
                                      

                                Show all comments
                                • Paulo (DevExpress Support) 12.10.2015

                                  Hello,

                                  The problem may be that the application is searching for some kind of the web printer. It is difficult to determine the cause of the problem without tracing the sample code. From what I gather, it should be possible to reproduce this scenario on a problematic machine using a regular DLL, but not only ActiveX. Such DLL can be debugged and traced to find the cause of this freezing.

                                • Delphi Developer 12.10.2015

                                  Hello Paulo.
                                  Since we have the source, I added debug output to all the procedures and functions in the dxPUtl unit and registered the DLL. This is what we see on a machine that has no problems:
                                  Bitmap_LoadFromResourceName
                                  Bitmap_LoadFromResourceName
                                  Bitmap_LoadFromResourceName
                                  Bitmap_LoadFromResourceName
                                  Bitmap_LoadFromResourceName
                                  Bitmap_LoadFromResourceName
                                  Bitmap_LoadFromResourceName
                                  Bitmap_LoadFromResourceName
                                  Bitmap_LoadFromResourceName
                                  GetMachineName
                                  GetUserName
                                  CreateGlyphBitmap
                                  initialization
                                  PopulateShellImages(True)
                                  PopulateShellImages
                                  IsWinNT
                                  ShellDLL=1980694528
                                  Proc=7611376B
                                  Result=-1
                                  finalization
                                  FreeAndNil(FDrawModeImages)
                                  FreeAndNil(FTrueTypeFonts)
                                  FreeAndNil(FNonTrueTypeFonts)
                                  FreeAndNil(FShellLargeImages)
                                  FreeAndNil(FShellSmallImages)
                                  On the one machine we have here where it hangs we see exactly the same situation as B146004. That is, the Proc(FullInit) called within PopulateShellImages fails.
                                  initialization
                                  PopulateShellImages(True)
                                  PopulateShellImages
                                  IsWinNT
                                  ShellDLL=1974730752
                                  Proc=75B6376B
                                  This would be a call to FileIconInit within the Shell32.dll.
                                  There is also an old discussion at Add-in Express about not using CoInitialize and CoUninitialize within a DLL, but we've tried that and it still hangs. I do wonder why you use PChar(660) in dxPUtl when GetProcAddress expects a PAnsiChar for the procedure name/ordinal, but changing it made no difference either.
                                  Do you have any ideas why this would hang? It should just be loading up an HIMAGELIST from disk, so I'm not sure how web printers are involved.

                                • Paulo (DevExpress Support) 12.11.2015

                                  I am afraid that for now we cannot say why this happens. Would you please comment PopulateShellImages in the source code? Does this fix the problem?

                                • Delphi Developer 08.22.2016

                                  I've had to come back to this as it seems that something has occurred in the last week to cause this problem to appear for people who previously had no issues, including myself.

                                  Given the timing it may be related to a Windows update that was rolled out, but the only one I can see in August is one for Adobe Acrobat Reader DC (15.017.20053), and uninstalling Acrobat Reader had no effect.

                                  Running my application in the IDE, at the point where I use the CoCreate to create the COM server within my DLL, the last module it loaded was dropbox_shell_ext.dll, and since we know the problem is from a call to Shell32.dll, it would seem that DropBox is to blame.

                                  Confirmed. After uninstalling DropBox, our application no longer hangs at the point where we are creating the COM server, and Regsvr32.exe is able to register/de-register the DLL correctly.

                                • Paulo (DevExpress Support) 08.23.2016

                                  Thank you for sharing your research results. I am happy to hear that uninstalling DropBox has resolved this issue. I believe this information will help other programmers who face a similar problem.

                                • Francesco Faleschini 08.24.2016

                                  I also had the same problem and Dropbox was the issue, even if i am not 100% sure it is DropBox alone

                                • Delphi Developer 08.24.2016

                                  Based on my search of the DropBox support posts, this has happened before in a prior release of that application. It's unfortunate that the FileIconInit method in Shell32.dll is not robust enough to handle shell extensions with problems. It may have been DropBox this time but the same situation could occur with any application that includes shell extensions.

                                  If this happens again, using a third-party utility program such as ShellExView from Nirsoft  would help in isolating which shell extension is causing the hang without needing to uninstall each one until the problem disappears.

                                  There doesn't seem to be anything that DevExpress can do either, as all they are doing is calling the method handle within the DLL. They cannot handle  the situation that processing never returns from that call, unless they never call that method in the first place.

                                0 Solutions

                                Creation Date Importance Sort by