Well the good news is that Jbpro failing IS PROBABLY A PROFILE issue.  The bad news it that it took me parts of 4 days and a lot of Windows craziness to confirm this.  I have always resisted having to sign in to my own darned computer,  so I used netplwiz magic to turn that requirement off.  Hit the power button, wait a few seconds and I'm in.  To create a new profile, I first needed to be able to sign in.  If you've forgotten your password that's not possible.  I went through several rounds of trying to prove my identify to MS and they are totally useless.  Tried many other approaches.  Without digressing too far, you need a new admin user.  In your C:\users directory a  profile will be created with the first four letters of that user's email (actually the first four of their id).  If you go through the appropriate set up password hoops (which are totally crazy and inconsistent) you eventually get a c:\users\newid record indicating a id you can sign into.  Do that (sign in) and run JBPRO from that and it works.  What's wrong with your "standard" profile is beyond me.  I could run file comparisons between the old profile where jbpro doesn't work and the new one.  But life is too short.  I can run it by signing on to the new profile or going to another computer where it works.   That's all I need and all I have time for. 

If somewhere there is someone actively supporting JBPRO (? Simpleviewer folks out in California?) they need to have a test setup with computers and software that people actually use ... which still includes Windows 10) and figure out what's going on.  It there is a developer actually working on this actively I'd be happy to share my experience but for now I have to move on.

Before I went through the pain of reinstalling Windows (I tried various system file checkers and resetters yesterday) I went to my wife's computer which runs the same version of Windows as mine).  We are both running Windows 22H2 and os build 19045.2846, for what that's worth.  The KernelBase files have identical file versions 10.0.19041.27788 and file sizes.  I went to the download site for JuiceboxPro which was provided by email.  Went through instructions for installing JuiceBoxPro on wife's computer including Adobe Air.  Both are running Air 33.1.1.744.  So that's identical and from what I can tell that's the correct version. 

Wife's computer was running JuiceboxPro 1.5.1 successfully within 5 minutes of starting install.  Mine still dies leaving the artifacts I have previously posted in the event viewer. 

Two computers.  Identical Windows versions.  Identical JuiceboxPro installations.  Same version of Adobe AIR.   Appears to be the same version of kernelbase.dll.  On one JuiceboxPro fails.  On the other it doesn't.   

I will reset Windows on the failing machine as time permits.  Any other suggestions appreciated.

Oh man!  Thank you.  If there is any way you can highlight this or emphasize it, I would bet there are a LOT OF USERS who would appreciate seeing it.  I just blew through 2 hours trying to diagnose this before stumbling across it in Forums.   

Maybe even change the Juicebox Builder Pro program where it says "view in browser" to put some kind of warning in. 

I realize that this Forum posting is a year and a half old, but that just means that a large majority of users are either not going to be able to use the preview or will have to tweak their settings.

http://fkelly.org

using the Drupal Juicebox module with galleries uploaded from the PC version of Juicebox Pro.  Many galleries, all accessed from Drupal Menus.  The tab named Sculpt and Print contains my wife's sculpture albums.  The albums are presented using a Drupal view which allows me to assign a "representative image" to each album and to order the albums any way I want.

Coming back to this topic after creating a bunch of galleries with these observations on captions.  And customizations. 

My wife and I manage our photos in Lightroom.  We add captions there and take the additional step of writing the metadata to the base files.  This is essential in my view, unless you like losing your work.  Tag and keyword the files too.  Then select groups of images to go in a Gallery.  Use export to put them in an /export/galleryname1 ... n folder safely outside the Lightroom catalog area.  Then verify results in Windows file explorer.  If you set the view for picture type folders to detail and show the title field you can verify that captions got written successfully. 

Now bring up Juicebox Pro.  Create a new gallery.  Bring in the files from /export/galleryname_n.  Now here's issue number one.  Unless you have the preset set to have captions use the IPTC caption field at this point, Juicebox will create the files for the gallery without embedding the metadata caption.  So, if I create the gallery in a directory /jbox/galleryname_n and look at the folder in windows file manager I see nothing in the title field (which is really the caption field).  You can set a preset to use the IPTC caption for the caption and, if you remember to load this first, the files will be created in the /jbox folders with the captions metadata. 

This leads to two questions ... which I will turn into feature requests if you confirm this.  1.  is there a way to set default preferences that will ALWAYS apply, even to new Galleries and unless explicitly overridden.  In other words so that you don't have to remember to load your preset every time.  What happens to us is that we occasionally forget to load the captions.xml preset.  Bring in the files.  Reorder the files by dragging them around in the order we intend for the Gallery.  Publish it and notice that captions aren't there.  Since Juicebox has not created files with captions metadata we can't just reread the files after changing that option.  And 2. which is not so much a question as a request for confirmation.  The files created for the juicebox images directory, if captions are off in presets, don't include metadata.  It would be really useful if they did, so you wouldn't have to delete everything and start over, including dragging the files around into the right order all over again.

In other words, the refresh that you mentioned in your 2016-06-24 response only works if Juicebox has copied over the image files with caption metadata and as far as I can tell it doesn't do that if captions are "off". 

It would also be helpful if you could shift-click or ctrl-click the list of images in a Gallery in order to delete them.  Again, I'll consolidate this into a feature request if there is no work around for this.

"Google seems to be slowing discontinuing support for the Picasa Web API. Existing galleries (created prior to Google acquiring Picasa) still display fine but new galleries (created or modified since the acquisition) can no longer be accessed via the API."

Google acquired Picasa years and years ago.  At first Picasa Web albums was their primary product for storing Photos on the web.  They've since moved to Google Plus, also tried using Google Drive, then to several iterations of Google Photos.  They do this arbitrarily and without any consulting with users, you just get a notice that things are changing.  Users protest in Forums and Google ignores them.  While your mileage may vary, a year go I saw the writing on the wall and moved my 6000+ pictures in 50+ albums from Picasa and Google, to being managed under Lightroom.  Then create Juicebox albums and move copies up to a Drupal 8 site, using the Juicebox module there.  You can keep full sized images under Lightroom, then resize them as needed for the web albums.  I assume this would work just fine for WP as it does in Drupal.  Just upload the albums and images with a FTP client and let PicasaWeb die a well deserved dusty death.

Stuart;
Nice to meet you.  Yes, the bats were eerie, spectacular too.

I haven't used views for this at all and am not sure I can help.  I think your albums content type is the equivalent to what I am calling a Juicebox Gallery content type.  The only field I have in mine is a body field.  I paste the embed code into it like this example:

<!--START JUICEBOX EMBED--><script src="/drupal8/sites/all/libraries/juicebox/juicebox.js"></script><script>
    new juicebox({
        baseUrl : '/drupal8/sites/default/files/jboxgalleries/rainforest/',
        containerId: 'juicebox-container',
        galleryWidth: '100%',
        galleryHeight: '100%',
        backgroundColor: '#222222'
    });
    </script>
<div id="juicebox-container">&nbsp;</div>
<!--END JUICEBOX EMBED-->

So, I have a content item named Australia Rainforest that is of the content type Juicebox Gallery.  I set a url for that album of /rainforest so I don't have to mess around with accessing "node" numbers.  Maybe tomorrow I'll mess around with setting up a view to point to /rainforest and see what I can do.  When you say "lightbox" what are you referring to?  The initial image in a Juicebox Gallery or something from the lightbox module.  I'm not even sure lightbox works with Drupal 8, I had it installed under Drupal 7 but there's a whole bunch of stuff that doesn't work in 8 yet.

As someone who has traveled this road ... converting from Photos on Google Photos (aka, Picasaweb aka Google+ Photos) your path of least resistance and most functionality might be to just arrange the photos in folders on your desktop computer, then use Juicebox Builder to build your galleries from the pics on your desktop and upload the appropriate galleries to your Drupal web site.  This way you are not (long term) held hostage to whatever access decisions Google makes.  The Picasa desktop product provides a good way to get your Google Photos files arranged on your desktop prior to making Juicebox Galleries out of them.  I had a pretty productive workflow going to create 50+ Juicebox galleries on my Drupal 8 web site ... organize the folders, use juicebox builder to create galleries, upload selected files to your site using FTP.  You really only need to upload the xml file and images and thumbnails directories to your site if you have the Drupal juicebox module set up there.  I created a menu for all my galleries too.

fkelly.org for an example.

RewriteCond %{REQUEST_URI} !/jboxgalleries/config.php$

in the drupal htaccess did the trick.  Thank you!

For what it's worth, I'm thinking that from a design, operations, and performance standpoint I may be better off putting the files on my own (hosted, inmotion,) server rather than drawing them from Google each time a Gallery is accessed.  I have >6000 photos on google divided in 88 albums (folders).  I have the same photos neatly arranged on my home PC and can use juiceboxbuilder to generate galleries quickly.  This way too all thumbnail generation is done once on the PC, which has plenty of resources and won't incur server overhead other than for presentation.  It's easy enough to set up menus listing the galleries with Drupal.  With ftp I can go from creating a gallery in builder to accessing it on the server in probably 10 minutes or less.  It's terrific.

I basically have set up a custom content type in Drupal just for juicebox galleries.  I can put the listing in a special menu just for galleries.  Eventually I can tag the individual galleries and use Drupal views to slice and dice however I want.

For what it's worth, Drupal has long been a dead end for galleries.  There are a couple of contributed modules I've used on Drupal 7 but (a) they are buggy and not supported and (b) there's little prospect they will be updated to run in Drupal 8. I think juicebox could be just a GREAT solution and I'll post this over in the Drupal forums when I get a few more examples done.