SOLVED

Add-in registry access problem

%3CLINGO-SUB%20id%3D%22lingo-sub-299525%22%20slang%3D%22en-US%22%3EAdd-in%20registry%20access%20problem%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-299525%22%20slang%3D%22en-US%22%3E%3CP%3EI%20am%20the%20author%20of%20an%20add-in%20(Rainbow%20Analyst)%20which%20retrieves%20certain%20stored%20user%20details%20from%20the%20Windows%20Registry%20during%20startup.%20This%20code%20has%20operated%20without%20any%20problem%20for%20some%20years%20now%2C%20but%20following%20the%20latest%20(November%202018)%20update%20to%20Windows%2010%201803%20and%2For%20Office%20365%20(64-bit%20version)%2C%20when%20I%20click%20an%20existing%20(i.e.%20Recent)%20Excel%20workbook%20in%20the%20Excel%20startup%20screen%2C%20Excel%20silently%20crashes%20(closes)%20before%20displaying%20the%20add-in.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20have%20traced%20the%20crash%20to%20the%20code%20which%20accesses%20the%20Registry%2C%20because%20although%20the%20crash%20occurs%20some%20time%20after%20this%20code%20is%20executed%2C%20it%20seems%20(from%20experiment)%20that%20it%20can%20only%20be%20prevented%20by%20eliminating%20this%20section%20of%20code%20(not%20feasible%20in%20practice%2C%20as%20essential%20user%20details%20are%20stored%20in%20the%20Registry).%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThere%20is%20no%20problem%20if%20I%20click%20%22Blank%20workbook%22%20and%20then%20subsequently%20open%20an%20existing%20workbook%2C%20and%20I%20have%20also%20ascertained%20that%20the%20crash%20only%20occurs%20when%20the%20Registry%20is%20accessed%20more%20than%20once%3B%20it%20can%20be%20avoided%20if%20I%20modify%20the%20code%20to%20limit%20it%20to%20a%20single%20Registry%20access%20(not%20feasible%20in%20practice).%20I%20currently%20use%20the%20VBA%20GetSetting%20function%2C%20but%20the%20same%20problem%20occurs%20if%20I%20create%20a%20WScript.Shell%20object%20and%20use%20the%20RegRead%20method.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20am%20new%20here%2C%20so%20I%20hope%20this%20is%20the%20correct%20place%20to%20raise%20this%20problem.%20Any%20suggestions%20will%20be%20much%20appreciated!%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-299525%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EMacros%20and%20VBA%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-299671%22%20slang%3D%22en-US%22%3ERe%3A%20Add-in%20registry%20access%20problem%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-299671%22%20slang%3D%22en-US%22%3EYou're%20welcome.%20I%20have%20fixed%20issues%20like%20these%20using%20this%20technique%20in%20quite%20some%20of%20my%20add-ins%20as%20available%20through%20%3CA%20href%3D%22https%3A%2F%2Fjkp-ads.com%2Fdownload.asp%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fjkp-ads.com%2Fdownload.asp%3C%2FA%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-299664%22%20slang%3D%22en-US%22%3ERe%3A%20Add-in%20registry%20access%20problem%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-299664%22%20slang%3D%22en-US%22%3EExcellent%3B%20this%20has%20solved%20the%20problem!%20I've%20set%20all%20custom%20tabs%20as%20initially%20invisible%2C%20then%20run%20the%20rest%20of%20the%20start-up%20code%20after%20one%20second%20and%20refreshed%20the%20ribbon%20(with%20.Invalidate)%2C%20and%20all%20works%20fine.%20Many%20thanks%20again%20for%20your%20help.%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-299589%22%20slang%3D%22en-US%22%3ERe%3A%20Add-in%20registry%20access%20problem%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-299589%22%20slang%3D%22en-US%22%3EMany%20thanks%20Jan%20Karel%20for%20this%20prompt%20and%20helpful%20response%3B%20much%20appreciated%2C%20and%20I'll%20certainly%20give%20this%20a%20go.%20There's%20a%20slight%20potential%20issue%20because%20the%20add-in%20uses%20the%20registry%20reads%20to%20determine%20what%20tab%20or%20icon%20to%20display%20on%20the%20Ribbon%20(using%20the%20isVisible%20property%20of%20the%20IRibbonControl%20objects)%2C%20but%20I%20guess%20it%20shouldn't%20be%20a%20problem%20to%20delay%20the%20Ribbon%20display%20by%20a%20fraction%20of%20a%20second.%20I'll%20try%20it%20and%20post%20again%20to%20confirm%20the%20outcome.%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-299563%22%20slang%3D%22en-US%22%3ERe%3A%20Add-in%20registry%20access%20problem%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-299563%22%20slang%3D%22en-US%22%3EDoes%20it%20help%20to%20postpone%20the%20registry%20reads%20until%20Excxel%20has%20really%20fininshed%20starting%20up%3F%20What%20I%20usually%20do%20to%20allow%20Excel%20to%20finish%20it's%20business%20during%20startup%20is%20(in%20Workbook_Open)%20schedule%20a%20macro%20called%20%22ContinueOpen%22%20situated%20in%20a%20normal%20module%20using%20Application.Ontime.%20This%20prevents%20all%20sorts%20of%20issues%20stemming%20from%20Excel%20not%20having%20finished%20to%20load%20completely%20when%20your%20Workbook_Open%20is%20called.%3C%2FLINGO-BODY%3E
Highlighted
New Contributor

I am the author of an add-in (Rainbow Analyst) which retrieves certain stored user details from the Windows Registry during startup. This code has operated without any problem for some years now, but following the latest (November 2018) update to Windows 10 1803 and/or Office 365 (64-bit version), when I click an existing (i.e. Recent) Excel workbook in the Excel startup screen, Excel silently crashes (closes) before displaying the add-in.

 

I have traced the crash to the code which accesses the Registry, because although the crash occurs some time after this code is executed, it seems (from experiment) that it can only be prevented by eliminating this section of code (not feasible in practice, as essential user details are stored in the Registry).

 

There is no problem if I click "Blank workbook" and then subsequently open an existing workbook, and I have also ascertained that the crash only occurs when the Registry is accessed more than once; it can be avoided if I modify the code to limit it to a single Registry access (not feasible in practice). I currently use the VBA GetSetting function, but the same problem occurs if I create a WScript.Shell object and use the RegRead method.

 

I am new here, so I hope this is the correct place to raise this problem. Any suggestions will be much appreciated!

4 Replies
Highlighted
Solution
Does it help to postpone the registry reads until Excxel has really fininshed starting up? What I usually do to allow Excel to finish it's business during startup is (in Workbook_Open) schedule a macro called "ContinueOpen" situated in a normal module using Application.Ontime. This prevents all sorts of issues stemming from Excel not having finished to load completely when your Workbook_Open is called.
Highlighted
Many thanks Jan Karel for this prompt and helpful response; much appreciated, and I'll certainly give this a go. There's a slight potential issue because the add-in uses the registry reads to determine what tab or icon to display on the Ribbon (using the isVisible property of the IRibbonControl objects), but I guess it shouldn't be a problem to delay the Ribbon display by a fraction of a second. I'll try it and post again to confirm the outcome.
Highlighted
Excellent; this has solved the problem! I've set all custom tabs as initially invisible, then run the rest of the start-up code after one second and refreshed the ribbon (with .Invalidate), and all works fine. Many thanks again for your help.
Highlighted
You're welcome. I have fixed issues like these using this technique in quite some of my add-ins as available through https://jkp-ads.com/download.asp