• unable to boot into safe mode

    From Jackson Durmott@21:1/5 to All on Sun Nov 17 18:10:52 2024
    All I've been trying to do is boot into safe mode Win 10, but
    impossible! Started off pressing the classic F4/8 keys at start up to
    no avail. I then proceeded into the msconfig to try selecting safe
    boot, but I am unable to place any check marks. I then tried an
    advanced start up and when restarted, all I am presented with is an
    option to turn off the PC.

    I then tried creating a recovery USB, but it won't create it. I even
    tried formatting the USB disc in NTSC, cleared it of data, and then made
    it bootable, but the recovery data still wouldn't install. The USB is
    32 GB size.

    I don't recall how I went about installing Win 10 as it has been so
    long, but I do keep system restore turned off because I do frequent back
    ups.

    I use a dual boot system with a GRUB menu at boot up where I can select
    either Ubuntu or Win 10. Once beyond the screen and Win 10 was
    selected, it is then that I've tried F4/8 and booting from USB to no
    avail.

    I just read recently to someone having the same issue to boot like three
    times, but shut down before start up is actually completed. After like
    the third attempt, a safe mode screen will be presented with options.
    This seems rather radical to me, but if it works, I might give it a try.
    Not sure it would work on my version of Win 10 though as I'm using
    version 1809.

    Suggestions welcome! All I want to do is some troubleshooting as I'm
    having difficulty with a certain program and wanted to try safe mode
    first to see if I could get it working correctly, but I can't reach safe
    mode!

    Thanks in advance.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jackson Durmott@21:1/5 to All on Sun Nov 17 18:28:45 2024
    T24gMTEvMTcvMjQgNjoxMCBQTSwgSmFja3NvbiBEdXJtb3R0IHdyb3RlOg0KPiBBbGwgSSd2 ZSBiZWVuIHRyeWluZyB0byBkbyBpcyBib290IGludG8gc2FmZSBtb2RlIFdpbiAxMCwgYnV0 IA0KPiBpbXBvc3NpYmxlIcKgIFN0YXJ0ZWQgb2ZmIHByZXNzaW5nIHRoZSBjbGFzc2ljIEY0 Lzgga2V5cyBhdCBzdGFydCB1cCB0byANCj4gbm8gYXZhaWwuwqAgSSB0aGVuIHByb2NlZWRl ZCBpbnRvIHRoZSBtc2NvbmZpZyB0byB0cnkgc2VsZWN0aW5nIHNhZmUgDQo+IGJvb3QsIGJ1 dCBJIGFtIHVuYWJsZSB0byBwbGFjZSBhbnkgY2hlY2sgbWFya3MuwqAgSSB0aGVuIHRyaWVk IGFuIA0KPiBhZHZhbmNlZCBzdGFydCB1cCBhbmQgd2hlbiByZXN0YXJ0ZWQsIGFsbCBJIGFt IHByZXNlbnRlZCB3aXRoIGlzIGFuIA0KPiBvcHRpb24gdG8gdHVybiBvZmYgdGhlIFBDLg0K PiANCj4gSSB0aGVuIHRyaWVkIGNyZWF0aW5nIGEgcmVjb3ZlcnkgVVNCLCBidXQgaXQgd29u J3QgY3JlYXRlIGl0LsKgIEkgZXZlbiANCj4gdHJpZWQgZm9ybWF0dGluZyB0aGUgVVNCIGRp c2MgaW4gTlRTQywgY2xlYXJlZCBpdCBvZiBkYXRhLCBhbmQgdGhlbiBtYWRlIA0KPiBpdCBi b290YWJsZSwgYnV0IHRoZSByZWNvdmVyeSBkYXRhIHN0aWxsIHdvdWxkbid0IGluc3RhbGwu wqAgVGhlIFVTQiBpcyANCj4gMzIgR0Igc2l6ZS4NCj4gDQo+IEkgZG9uJ3QgcmVjYWxsIGhv dyBJIHdlbnQgYWJvdXQgaW5zdGFsbGluZyBXaW4gMTAgYXMgaXQgaGFzIGJlZW4gc28gDQo+ IGxvbmcsIGJ1dCBJIGRvIGtlZXAgc3lzdGVtIHJlc3RvcmUgdHVybmVkIG9mZiBiZWNhdXNl IEkgZG8gZnJlcXVlbnQgYmFjayANCj4gdXBzLg0KPiANCj4gSSB1c2UgYSBkdWFsIGJvb3Qg c3lzdGVtIHdpdGggYSBHUlVCIG1lbnUgYXQgYm9vdCB1cCB3aGVyZSBJIGNhbiBzZWxlY3Qg DQo+IGVpdGhlciBVYnVudHUgb3IgV2luIDEwLsKgIE9uY2UgYmV5b25kIHRoZSBzY3JlZW4g YW5kIFdpbiAxMCB3YXMgDQo+IHNlbGVjdGVkLCBpdCBpcyB0aGVuIHRoYXQgSSd2ZSB0cmll ZCBGNC84IGFuZCBib290aW5nIGZyb20gVVNCIHRvIG5vIGF2YWlsLg0KPiANCj4gSSBqdXN0 IHJlYWQgcmVjZW50bHkgdG8gc29tZW9uZSBoYXZpbmcgdGhlIHNhbWUgaXNzdWUgdG8gYm9v dCBsaWtlIHRocmVlIA0KPiB0aW1lcywgYnV0IHNodXQgZG93biBiZWZvcmUgc3RhcnQgdXAg aXMgYWN0dWFsbHkgY29tcGxldGVkLsKgIEFmdGVyIGxpa2UgDQo+IHRoZSB0aGlyZCBhdHRl bXB0LCBhIHNhZmUgbW9kZSBzY3JlZW4gd2lsbCBiZSBwcmVzZW50ZWQgd2l0aCBvcHRpb25z LiANCj4gVGhpcyBzZWVtcyByYXRoZXIgcmFkaWNhbCB0byBtZSwgYnV0IGlmIGl0IHdvcmtz LCBJIG1pZ2h0IGdpdmUgaXQgYSB0cnkuIA0KPiAgwqBOb3Qgc3VyZSBpdCB3b3VsZCB3b3Jr IG9uIG15IHZlcnNpb24gb2YgV2luIDEwIHRob3VnaCBhcyBJJ20gdXNpbmcgDQo+IHZlcnNp b24gMTgwOS4NCj4gDQo+IFN1Z2dlc3Rpb25zIHdlbGNvbWUhwqAgQWxsIEkgd2FudCB0byBk byBpcyBzb21lIHRyb3VibGVzaG9vdGluZyBhcyBJJ20gDQo+IGhhdmluZyBkaWZmaWN1bHR5 IHdpdGggYSBjZXJ0YWluIHByb2dyYW0gYW5kIHdhbnRlZCB0byB0cnkgc2FmZSBtb2RlIA0K PiBmaXJzdCB0byBzZWUgaWYgSSBjb3VsZCBnZXQgaXQgd29ya2luZyBjb3JyZWN0bHksIGJ1 dCBJIGNhbid0IHJlYWNoIHNhZmUgDQo+IG1vZGUhDQo+IA0KPiBUaGFua3MgaW4gYWR2YW5j ZS4NCg0KT2ssIHNvIHRyaWVkIHRoZSBoYXJkIHNodXQgZG93biBtZXRob2QuICBBZnRlciB0 aGUgdGhpcmQgdGltZSwgd2FzIA0KcHJlc2VudGVkIHdpdGggYSBzY3JlZW4gd2hlcmUgSSBj aG9zZSB0cm91Ymxlc2hvb3RpbmctPmFkdmFuY2VkLT5zdGFydCANCnVwIHNldHRpbmdzLT4g cmVzdGFydC4gIEd1ZXNzIHdoYXQsIHN0aWxsIGJvb3RzIG5vcm1hbGx5IHdpdGggbm8gc2Fm ZSBvciANCm90aGVyIG9wdGlvbnMgcHJlc2VudGVkIQ0K

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jackson Durmott@21:1/5 to All on Sun Nov 17 21:09:45 2024
    I got it to work. I had to go into Win 10 disk management and set the
    "system reserved" status to "active." Once I did that, I was presented
    with the safe boot option in the config menu and, upon rebooting, Win 10
    went into safe mode. Two quick questions: 1) Why was this partition not already active? and 2) Will it hurt anything to leave it as active now?
    Remember that I use dual boot (Win/ Ubuntu) through GRUB. Thank you.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to Jackson Durmott on Sun Nov 17 21:12:40 2024
    On Sun, 11/17/2024 6:28 PM, Jackson Durmott wrote:
    On 11/17/24 6:10 PM, Jackson Durmott wrote:
    All I've been trying to do is boot into safe mode Win 10, but impossible!  Started off pressing the classic F4/8 keys at start up to no avail.  I then proceeded into the msconfig to try selecting safe boot, but I am unable to place any check marks. 
    I then tried an advanced start up and when restarted, all I am presented with is an option to turn off the PC.

    I then tried creating a recovery USB, but it won't create it.  I even tried formatting the USB disc in NTSC, cleared it of data, and then made it bootable, but the recovery data still wouldn't install.  The USB is 32 GB size.

    I don't recall how I went about installing Win 10 as it has been so long, but I do keep system restore turned off because I do frequent back ups.

    I use a dual boot system with a GRUB menu at boot up where I can select either Ubuntu or Win 10.  Once beyond the screen and Win 10 was selected, it is then that I've tried F4/8 and booting from USB to no avail.

    I just read recently to someone having the same issue to boot like three times, but shut down before start up is actually completed.  After like the third attempt, a safe mode screen will be presented with options. This seems rather radical to me,
    but if it works, I might give it a try.   Not sure it would work on my version of Win 10 though as I'm using version 1809.

    Suggestions welcome!  All I want to do is some troubleshooting as I'm having difficulty with a certain program and wanted to try safe mode first to see if I could get it working correctly, but I can't reach safe mode!

    Thanks in advance.

    Ok, so tried the hard shut down method.  After the third time, was presented with a screen where I chose troubleshooting->advanced->start up settings-> restart.  Guess what, still boots normally with no safe or other options presented!

    I did one of these just yesterday, but the situation was different than normal.

    In a legacy boot (MSDOS partitioning, C: is a primary partition), the BCD
    file (a kind of registry file with boot menu info) is on C: . If I boot a Windows installer DVD, select "Troubleshooting" instead of installation,
    there is a Command Prompt window there.

    dir C:\boot\BCD # Check for a visible file
    dir /AH C:\boot\BCD # Check for the BCD file as a hidden file

    bcdedit /store C:\boot\BCD /set {bootmgr} displaybootmenu True # This gives an F8 option in the boot menu

    My assumption is always, that the user is locked out of their OS, and they are using a boot DVD for the Command Prompt it can provide. The command as shown
    is an "offline command", meaning the OS on C: is not running at the time you add F8.

    If C: was healthy, you were booted into it, and you just wanted to add F8 for fun, it would be
    like this. The OS knows where the BCD is, and we don't have to state which BCD we want to fix.

    bcdedit /set {bootmgr} displaybootmenu True

    *******

    Now, on a GPT disk, we get our hands a bit dirty for the offline case.
    The picture shows the context for what I'm doing.

    [Picture]

    https://i.postimg.cc/qBGGVxY7/GPT-EFI-Boot-materials-BCD.gif

    diskpart
    list disk
    select disk 0 # This is the disk which we know has our boot OS on it
    list partition # Typically, the first partition is 100MB, it is FAT32, it has boot goodies in it.
    select partition 1 # Select the 100MB partition, which is also known as the ESP, or EFI System Partition.
    assign letter=K # Make the partition have the letter K: temporarily while we work on it.
    exit # Exit diskpart

    K: # Now we look around.
    dir # Examining folders in boot area
    cd EFI\Microsoft\Boot # I had to check my current drive (with TestDisk) to verify this is the target

    The idea is, eventually we know for sure where the BCD file is.
    We craft our offline command for a GPT partitioned disk.

    bcdedit /store K:\EFI\Microsoft\Boot\BCD /set {bootmgr} displaybootmenu True

    If you then did

    bcdedit /store K:\EFI\Microsoft\Boot\BCD

    you should be able to see your new displaybootmenu entry in the menu printout.

    You can exit from the current DVD session, and reboot to the drive.
    You should see a black WinXP-era menu, with an F8 entry below the OS entry. Press F8.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to Jackson Durmott on Mon Nov 18 11:54:36 2024
    On Sun, 11/17/2024 9:09 PM, Jackson Durmott wrote:
    I got it to work. 

    I had to go into Win 10 disk management and set the "system reserved" status to "active." 

    Once I did that, I was presented with the safe boot option in the config menu and,
    upon rebooting, Win 10 went into safe mode. 

    Two quick questions:

    1) Why was this partition not already active?  and
    2) Will it hurt anything to leave it as active now?

    Remember that I use dual boot (Win/ Ubuntu) through GRUB.  Thank you.

    [Picture]

    https://i.postimg.cc/XY9zncWD/WIN10-RLS-SSD-Legacy-MBR-Active.gif

    That's a picture of an MSDOS partitioned disk. The reason C: is marked
    Active, is because C: has

    C:\Boot\BCD

    which is what the Windows boot process would be looking for at some point.
    That BCD file, presents multiple Windows OSes if available and you
    can pick one of them.

    You can still have an Active somewhere other than C: , but then
    the partition needs an X:\Boot\BCD file. If C: is corrupted for example
    or if C: is protected by Bitlocker, then the BCD file may be put
    somewhere else.

    The Active flag has nothing to do with Linux, and nothing to do with GRUB.
    But once GRUB hands off (chainloads or whatever) the Windows Boot Manager,
    then you may see a Windows Boot menu if more than one Windows OS is present.

    Mine doesn't match yours. And I'm not sure I can convince it to make
    partitions labeled exactly like yours.

    I could put a GRUB and a Linux OS on the end of that disk, but
    it would be tricky. The drive doesn't have much space. And that
    OS was transferred to another device. I've already installed two Linux
    today :-) [working on the VirtualBox puzzle, what a mess]

    Summary: Active is mostly irrelevant, except when you lose it of course.
    You assign it to a partition that has the next stage of boot on it.
    Such files could be on more partition than one (I don't think there
    is a housecleaning function to remove them).

    It doesn't work the same way on UEFI/GPT, but your system may be older
    and a Free Upgrade from Windows 7. Which is why your partitions could
    be labeled the way they are.

    A boot repair routine, could mess around with the details. But
    one thing that does not have, is files for repairing the boot folder
    contents. There are tools to make a new BCD, but not tools to make
    the assorted other files in the folder. That is partially why the
    Recovery scan the other machine was doing for me, was a waste of time.
    I had to reinstall that to recover it.

    Since your setup is working, you can leave the Active as is.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jackson Durmott@21:1/5 to All on Tue Nov 19 17:17:07 2024
    T24gMTEvMTgvMjQgMTE6NTQgQU0sIFBhdWwgd3JvdGU6DQo+IE9uIFN1biwgMTEvMTcvMjAy NCA5OjA5IFBNLCBKYWNrc29uIER1cm1vdHQgd3JvdGU6DQo+PiBJIGdvdCBpdCB0byB3b3Jr Lg0KPj4NCj4+IEkgaGFkIHRvIGdvIGludG8gV2luIDEwIGRpc2sgbWFuYWdlbWVudCBhbmQg c2V0IHRoZSAic3lzdGVtIHJlc2VydmVkIiBzdGF0dXMgdG8gImFjdGl2ZS4iDQo+Pg0KPj4g T25jZSBJIGRpZCB0aGF0LCBJIHdhcyBwcmVzZW50ZWQgd2l0aCB0aGUgc2FmZSBib290IG9w dGlvbiBpbiB0aGUgY29uZmlnIG1lbnUgYW5kLA0KPj4gdXBvbiByZWJvb3RpbmcsIFdpbiAx MCB3ZW50IGludG8gc2FmZSBtb2RlLg0KPj4NCj4+IFR3byBxdWljayBxdWVzdGlvbnM6DQo+ Pg0KPj4gMSkgV2h5IHdhcyB0aGlzIHBhcnRpdGlvbiBub3QgYWxyZWFkeSBhY3RpdmU/wqAg YW5kDQo+PiAyKSBXaWxsIGl0IGh1cnQgYW55dGhpbmcgdG8gbGVhdmUgaXQgYXMgYWN0aXZl IG5vdz8NCj4+DQo+PiBSZW1lbWJlciB0aGF0IEkgdXNlIGR1YWwgYm9vdCAoV2luLyBVYnVu dHUpIHRocm91Z2ggR1JVQi7CoCBUaGFuayB5b3UuDQo+IA0KPiAgICAgW1BpY3R1cmVdDQo+ IA0KPiAgICAgIGh0dHBzOi8vaS5wb3N0aW1nLmNjL1hZOXpuY1dEL1dJTjEwLVJMUy1TU0Qt TGVnYWN5LU1CUi1BY3RpdmUuZ2lmDQo+IA0KPiBUaGF0J3MgYSBwaWN0dXJlIG9mIGFuIE1T RE9TIHBhcnRpdGlvbmVkIGRpc2suIFRoZSByZWFzb24gQzogaXMgbWFya2VkDQo+IEFjdGl2 ZSwgaXMgYmVjYXVzZSBDOiBoYXMNCj4gDQo+ICAgICBDOlxCb290XEJDRA0KPiANCj4gd2hp Y2ggaXMgd2hhdCB0aGUgV2luZG93cyBib290IHByb2Nlc3Mgd291bGQgYmUgbG9va2luZyBm b3IgYXQgc29tZSBwb2ludC4NCj4gVGhhdCBCQ0QgZmlsZSwgcHJlc2VudHMgbXVsdGlwbGUg V2luZG93cyBPU2VzIGlmIGF2YWlsYWJsZSBhbmQgeW91DQo+IGNhbiBwaWNrIG9uZSBvZiB0 aGVtLg0KPiANCj4gWW91IGNhbiBzdGlsbCBoYXZlIGFuIEFjdGl2ZSBzb21ld2hlcmUgb3Ro ZXIgdGhhbiBDOiAsIGJ1dCB0aGVuDQo+IHRoZSBwYXJ0aXRpb24gbmVlZHMgYW4gWDpcQm9v dFxCQ0QgZmlsZS4gSWYgQzogaXMgY29ycnVwdGVkIGZvciBleGFtcGxlDQo+IG9yIGlmIEM6 IGlzIHByb3RlY3RlZCBieSBCaXRsb2NrZXIsIHRoZW4gdGhlIEJDRCBmaWxlIG1heSBiZSBw dXQNCj4gc29tZXdoZXJlIGVsc2UuDQo+IA0KPiBUaGUgQWN0aXZlIGZsYWcgaGFzIG5vdGhp bmcgdG8gZG8gd2l0aCBMaW51eCwgYW5kIG5vdGhpbmcgdG8gZG8gd2l0aCBHUlVCLg0KPiBC dXQgb25jZSBHUlVCIGhhbmRzIG9mZiAoY2hhaW5sb2FkcyBvciB3aGF0ZXZlcikgdGhlIFdp bmRvd3MgQm9vdCBNYW5hZ2VyLA0KPiB0aGVuIHlvdSBtYXkgc2VlIGEgV2luZG93cyBCb290 IG1lbnUgaWYgbW9yZSB0aGFuIG9uZSBXaW5kb3dzIE9TIGlzIHByZXNlbnQuDQo+IA0KPiBN aW5lIGRvZXNuJ3QgbWF0Y2ggeW91cnMuIEFuZCBJJ20gbm90IHN1cmUgSSBjYW4gY29udmlu Y2UgaXQgdG8gbWFrZQ0KPiBwYXJ0aXRpb25zIGxhYmVsZWQgZXhhY3RseSBsaWtlIHlvdXJz Lg0KPiANCj4gSSBjb3VsZCBwdXQgYSBHUlVCIGFuZCBhIExpbnV4IE9TIG9uIHRoZSBlbmQg b2YgdGhhdCBkaXNrLCBidXQNCj4gaXQgd291bGQgYmUgdHJpY2t5LiBUaGUgZHJpdmUgZG9l c24ndCBoYXZlIG11Y2ggc3BhY2UuIEFuZCB0aGF0DQo+IE9TIHdhcyB0cmFuc2ZlcnJlZCB0 byBhbm90aGVyIGRldmljZS4gSSd2ZSBhbHJlYWR5IGluc3RhbGxlZCB0d28gTGludXgNCj4g dG9kYXkgOi0pIFt3b3JraW5nIG9uIHRoZSBWaXJ0dWFsQm94IHB1enpsZSwgd2hhdCBhIG1l c3NdDQo+IA0KPiBTdW1tYXJ5OiBBY3RpdmUgaXMgbW9zdGx5IGlycmVsZXZhbnQsIGV4Y2Vw dCB3aGVuIHlvdSBsb3NlIGl0IG9mIGNvdXJzZS4NCj4gICAgICAgICAgIFlvdSBhc3NpZ24g aXQgdG8gYSBwYXJ0aXRpb24gdGhhdCBoYXMgdGhlIG5leHQgc3RhZ2Ugb2YgYm9vdCBvbiBp dC4NCj4gICAgICAgICAgIFN1Y2ggZmlsZXMgY291bGQgYmUgb24gbW9yZSBwYXJ0aXRpb24g dGhhbiBvbmUgKEkgZG9uJ3QgdGhpbmsgdGhlcmUNCj4gICAgICAgICAgIGlzIGEgaG91c2Vj bGVhbmluZyBmdW5jdGlvbiB0byByZW1vdmUgdGhlbSkuDQo+IA0KPiAgICAgICAgICAgSXQg ZG9lc24ndCB3b3JrIHRoZSBzYW1lIHdheSBvbiBVRUZJL0dQVCwgYnV0IHlvdXIgc3lzdGVt IG1heSBiZSBvbGRlcg0KPiAgICAgICAgICAgYW5kIGEgRnJlZSBVcGdyYWRlIGZyb20gV2lu ZG93cyA3LiBXaGljaCBpcyB3aHkgeW91ciBwYXJ0aXRpb25zIGNvdWxkDQo+ICAgICAgICAg ICBiZSBsYWJlbGVkIHRoZSB3YXkgdGhleSBhcmUuDQo+IA0KPiAgICAgICAgICAgQSBib290 IHJlcGFpciByb3V0aW5lLCBjb3VsZCBtZXNzIGFyb3VuZCB3aXRoIHRoZSBkZXRhaWxzLiBC dXQNCj4gICAgICAgICAgIG9uZSB0aGluZyB0aGF0IGRvZXMgbm90IGhhdmUsIGlzIGZpbGVz IGZvciByZXBhaXJpbmcgdGhlIGJvb3QgZm9sZGVyDQo+ICAgICAgICAgICBjb250ZW50cy4g VGhlcmUgYXJlIHRvb2xzIHRvIG1ha2UgYSBuZXcgQkNELCBidXQgbm90IHRvb2xzIHRvIG1h a2UNCj4gICAgICAgICAgIHRoZSBhc3NvcnRlZCBvdGhlciBmaWxlcyBpbiB0aGUgZm9sZGVy LiBUaGF0IGlzIHBhcnRpYWxseSB3aHkgdGhlDQo+ICAgICAgICAgICBSZWNvdmVyeSBzY2Fu IHRoZSBvdGhlciBtYWNoaW5lIHdhcyBkb2luZyBmb3IgbWUsIHdhcyBhIHdhc3RlIG9mIHRp bWUuDQo+ICAgICAgICAgICBJIGhhZCB0byByZWluc3RhbGwgdGhhdCB0byByZWNvdmVyIGl0 Lg0KPiANCj4gICAgICAgICAgIFNpbmNlIHlvdXIgc2V0dXAgaXMgd29ya2luZywgeW91IGNh biBsZWF2ZSB0aGUgQWN0aXZlIGFzIGlzLg0KPiANCj4gICAgIFBhdWwNCg0KVGhhbmsgeW91 IGZvciB0aGUgY29uZmlybWF0aW9uISAgV2VsbCwgdGhlIHdob2xlIHJlYXNvbiBJIHdhcyBi b290aW5nIA0KaW50byBzYWZlIG1vZGUgd2FzIHRvIHNlZSBpZiBJIGNvdWxkIGdldCBvbmUg b2YgbXkgcHJvZ3JhbXMgd29ya2luZy4gIEl0IA0KaXMgYW4gYXN0cm9ub21pY2FsIHByb2dy YW0gdGhhdCBJIHJlY2VudGx5IGluc3RhbGxlZCBpbiBXaW4gMTAuICBUaGUgDQpwcm9ibGVt IGlzIHRoYXQgd2hlbiBJIHRyeSBhbmQgc3RhcnQgdGhlIHByb2dyYW0sIEkgZ2V0IGFuIGVy cm9yIGJveCANCndpdGggdGhlIGZpbmFsIG1lc3NhZ2Ugc2F5aW5nICJJbXBvcnRFcnJvcjog RExMIGxvYWQgZmFpbGVkIHdoaWxlIA0KaW1wb3J0aW5nIG9ubnhydW50aW1lX3B5YmluZDEx X3N0YXRlOiBUaGUgc3BlY2lmaWVkIG1vZHVsZSBjb3VsZCBub3QNCmJlIGZvdW5kLiINCg0K VGhlIHByb2dyYW0gZGV2ZWxvcGVycyBzYXkgdGhlIG1lc3NhZ2UgaGFzIHRvIGRvIHdpdGgg aGFyZHdhcmUgDQphY2NlbGVyYXRpb24gYW5kIHRvIGRpc2FibGUgaXQgZm9yIHRoZSBwcm9n cmFtIHRvIHJ1bi4gIEluIHRoZWlyIG1vc3QgDQpyZWNlbnQgdXBkYXRlLCB0aGV5IGFkZGVk IGFuIG9wdGlvbiB3aXRoaW4gdGhlaXIgcHJvZ3JhbSB0byBkaXNhYmxlIA0KaGFyZHdhcmUg YWNjZWxlcmF0aW9uLCBidXQgSSBjYW5ub3Qgb2YgY291cnNlIHN0YXJ0IHVwIHRoZSBwcm9n cmFtIA0Kd2l0aG91dCB0aGUgYWZvcmVtZW50aW9uZWQgZXJyb3IgbWVzc2FnZSBib3guICBU aGVyZWZvcmUsIEkgaGFkIGhvcGVkIGEgDQpzYWZlIHN0YXJ0IHdvdWxkIGRpc2FibGUgaGFy ZHdhcmUgYWNjZWxlcmF0aW9uLCBidXQgZGlkIG5vdCBtYWtlIGFueSANCmRpZmZlcmVuY2Ug YXMgdGhlIHByb2dyYW0gc3RpbGwgd291bGRuJ3Qgc3RhcnQuDQoNCk15IFdpbiBzeXN0ZW0g dXNlcyBXaW4gMTAgYnVpbGQgMTgwOSBhbmQgaGFzIGxpbWl0ZWQgSW50ZXJuZXQgYWNjZXNz LiANCk15IHZpZGVvIGNhcmQgaXMgUmFkZW9uIEhEIDM4NzAuICBPdGhlciB0aGFuIHRyeWlu ZyBzYWZlIG1vZGUgdG8gaGFsdCANCmhhcmR3YXJlIGFjY2VsZXJhdGlvbiwgSSdtIG5vdCBz dXJlIGhvdyB0byBkaXNhYmxlIGl0IG9uIHRoaXMgb2xkIERlbGwgDQpYUFMgNDIwLiAgSSd2 ZSBjaGVja2VkIHRoZSBCSU9TIHNldHRpbmdzLCBidXQgZG9uJ3Qgc2VlIGFueXRoaW5nIA0K Y29uY2VybmluZyBpdC4NCg0KVGhlIHByb2dyYW0gaXMgY2FsbGVkIEdyYVhwZXJ0IGFuZCBp cyBhdmFpbGFibGUgb24gR2l0aHViLiAgSXQgcnVucyBmaW5lIA0KZm9yIG1lIG9uIFVidW50 dSAyMi4wNCwgYnV0IG1vc3Qgb2YgbXkgYXN0cm9ub215IHByb2dyYW1zIGFyZSBvbiBXaW4u IA0KR3JhWHBlcnQgYWxzbyBydW5zIGJ5IGNvbW1hbmQgbGluZS4gIEkndmUgdHJpZWQgdG8g ZGlzYWJsZSBoYXJkd2FyZSANCmFjY2VsZXJhdGlvbiB0aGlzIHdheSBhcyB3ZWxsLCBidXQg c3RpbGwgZ2V0IHRoZSBlcnJvciBtZXNzYWdlIGJveC4NCg0KSSB3YXNuJ3QgZ29pbmcgdG8g Z28gZnVydGhlciBoZXJlLCBidXQgc2luY2UgeW91IHdlcmUgc28gaGVscGZ1bCBhbmQgDQp0 aG9yb3VnaCB3aXRoIFdpbiwgSSB0aG91Z2h0IHlvdSBtaWdodCBoYXZlIGFuIGlkZWEgb3Ig dHdvLg0KDQogIGh0dHBzOi8vZ2l0aHViLmNvbS9TdGVmZmVuaGlyL0dyYVhwZXJ0L3JlbGVh c2VzDQoNCkkgd2FzIHRyeWluZyB0byBwZXJoYXBzIGZpbmQgYSBmaWxlIChhbmQgbW9kaWZ5 IGl0KSBpbiB0aGUgZm9sZGVycyBpdCANCmluc3RhbGxlZCBvbiBXaW4gd2hlcmUgSSBtaWdo dCBiZSBhYmxlIHRvIGRpc2FibGUgaGFyZHdhcmUgYWNjZWxlcmF0aW9uLCANCmJ1dCBubyBs dWNrLg0KDQoNCg==

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to Jackson Durmott on Tue Nov 19 19:36:39 2024
    On Tue, 11/19/2024 5:17 PM, Jackson Durmott wrote:
    On 11/18/24 11:54 AM, Paul wrote:
    On Sun, 11/17/2024 9:09 PM, Jackson Durmott wrote:
    I got it to work.

    I had to go into Win 10 disk management and set the "system reserved" status to "active."

    Once I did that, I was presented with the safe boot option in the config menu and,
    upon rebooting, Win 10 went into safe mode.

    Two quick questions:

    1) Why was this partition not already active?  and
    2) Will it hurt anything to leave it as active now?

    Remember that I use dual boot (Win/ Ubuntu) through GRUB.  Thank you.

        [Picture]

         https://i.postimg.cc/XY9zncWD/WIN10-RLS-SSD-Legacy-MBR-Active.gif >>
    That's a picture of an MSDOS partitioned disk. The reason C: is marked
    Active, is because C: has

        C:\Boot\BCD

    which is what the Windows boot process would be looking for at some point. >> That BCD file, presents multiple Windows OSes if available and you
    can pick one of them.

    You can still have an Active somewhere other than C: , but then
    the partition needs an X:\Boot\BCD file. If C: is corrupted for example
    or if C: is protected by Bitlocker, then the BCD file may be put
    somewhere else.

    The Active flag has nothing to do with Linux, and nothing to do with GRUB. >> But once GRUB hands off (chainloads or whatever) the Windows Boot Manager, >> then you may see a Windows Boot menu if more than one Windows OS is present. >>
    Mine doesn't match yours. And I'm not sure I can convince it to make
    partitions labeled exactly like yours.

    I could put a GRUB and a Linux OS on the end of that disk, but
    it would be tricky. The drive doesn't have much space. And that
    OS was transferred to another device. I've already installed two Linux
    today :-) [working on the VirtualBox puzzle, what a mess]

    Summary: Active is mostly irrelevant, except when you lose it of course.
              You assign it to a partition that has the next stage of boot on it.
              Such files could be on more partition than one (I don't think there
              is a housecleaning function to remove them).

              It doesn't work the same way on UEFI/GPT, but your system may be older
              and a Free Upgrade from Windows 7. Which is why your partitions could
              be labeled the way they are.

              A boot repair routine, could mess around with the details. But
              one thing that does not have, is files for repairing the boot folder
              contents. There are tools to make a new BCD, but not tools to make
              the assorted other files in the folder. That is partially why the
              Recovery scan the other machine was doing for me, was a waste of time.
              I had to reinstall that to recover it.

              Since your setup is working, you can leave the Active as is.

        Paul

    Thank you for the confirmation!  Well, the whole reason I was booting into safe mode was to see if I could get one of my programs working.  It is an astronomical program that I recently installed in Win 10.  The problem is that when I try and start
    the program, I get an error box with the final message saying "ImportError: DLL load failed while importing onnxruntime_pybind11_state: The specified module could not
    be found."

    The program developers say the message has to do with hardware acceleration and to disable it for the program to run.  In their most recent update, they added an option within their program to disable hardware acceleration, but I cannot of course
    start up the program without the aforementioned error message box.  Therefore, I had hoped a safe start would disable hardware acceleration, but did not make any difference as the program still wouldn't start.

    My Win system uses Win 10 build 1809 and has limited Internet access. My video card is Radeon HD 3870.  Other than trying safe mode to halt hardware acceleration, I'm not sure how to disable it on this old Dell XPS 420.  I've checked the BIOS
    settings, but don't see anything concerning it.

    The program is called GraXpert and is available on Github.  It runs fine for me on Ubuntu 22.04, but most of my astronomy programs are on Win. GraXpert also runs by command line.  I've tried to disable hardware acceleration this way as well, but
    still get the error message box.

    I wasn't going to go further here, but since you were so helpful and thorough with Win, I thought you might have an idea or two.

     https://github.com/Steffenhir/GraXpert/releases

    I was trying to perhaps find a file (and modify it) in the folders it installed on Win where I might be able to disable hardware acceleration, but no luck.



    It says right on the GITHUB that

    GraXpert now links to onnxruntime 1.20. For Linux, this implies a dependency to CUDA 12 and cudnn 9.

    CUDA 12 means an NVidia card. A Radeon HD3870 doesn't have CUDA.

    You code for OpenCL if wanting to work in more places :-)

    On this topic area, even when you have an NVidia card, you
    can't get these FOSS programs to actually use the GPU. 99%
    of the time, you're doing your computing on the CPU anyway.
    Then if you did get it hooked up, there are tuning parameters
    which are power-of-two numbers. Some Devs, they
    "get it working on their card" and that's the end of tuning.

    If you were feeling some sort of anxiety, from not having an
    NVidia, trust me, that's only a tiny part of the mountain
    you must climb.

    As you surmise, your mission is to find that Preference setting.

    *******

    Page 13 of 17 pages.

    https://www.deepskyforge.com/documents/GraXpertProcess4PixInsight-EN.pdf

    C:\Users\username\AppData\Local\GraXpert\GraXpert\preferences.json <=== Open in Notepad

    C:\Users\username\AppData\Local\GraXpert\GraXpert\Logs\graxpert.log

    In File Explorer, you may find an "Options" which opens an old dialog
    from the WinXP era "Folder Options". The "View" tab has "Hidden Files and Folders",
    and I presume that's the one that makes AppData visible for easy navigation. Click Apply, and then Apply to Folders, so every bit of your disk can
    enjoy newfound "freedom" :-)

    Then, using Notepad, open the preferences.json and have a look around.

    I would not expect anyone to document at that level, so that's
    about as close as I can get you to the hardware acceleration entry.
    It might be in there, but I would not be able to tell otherwise,
    without installing it.

    You may comment "what a strange place to put a file". I suspect this
    is the C:\Program Files bypass. If a Dev started development in the
    WinXP era, some of them would store your Preferences file in the
    Program Files folder. This folder is owned by TrustedInstaller now.
    A user does not have editing rights for stuff in that folder.
    It could be, for example C:\Program Files\GraXpert where the developer
    stored the "preferences.json". Yet, the OS actually stored such
    materials in a deflection folder. The AppData folder above, the "username" account owns the file. This means editing in Notepad, stands
    a chance of working in there.

    Best Guess,
    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jackson Durmott@21:1/5 to Paul on Wed Nov 20 14:50:50 2024
    On 11/19/24 7:36 PM, Paul wrote:


    It says right on the GITHUB that

    GraXpert now links to onnxruntime 1.20. For Linux, this implies a dependency to CUDA 12 and cudnn 9.

    CUDA 12 means an NVidia card. A Radeon HD3870 doesn't have CUDA.

    You code for OpenCL if wanting to work in more places :-)

    On this topic area, even when you have an NVidia card, you
    can't get these FOSS programs to actually use the GPU. 99%
    of the time, you're doing your computing on the CPU anyway.
    Then if you did get it hooked up, there are tuning parameters
    which are power-of-two numbers. Some Devs, they
    "get it working on their card" and that's the end of tuning.

    If you were feeling some sort of anxiety, from not having an
    NVidia, trust me, that's only a tiny part of the mountain
    you must climb.

    I wonder why I have no issues with the same PC and video card when using
    the program in Ubuntu? In fact, I don't even have the hardware
    acceleration disabled and it works fine.


    As you surmise, your mission is to find that Preference setting.

    *******

    Page 13 of 17 pages.

    https://www.deepskyforge.com/documents/GraXpertProcess4PixInsight-EN.pdf

    C:\Users\username\AppData\Local\GraXpert\GraXpert\preferences.json <=== Open in Notepad

    C:\Users\username\AppData\Local\GraXpert\GraXpert\Logs\graxpert.log

    In File Explorer, you may find an "Options" which opens an old dialog
    from the WinXP era "Folder Options". The "View" tab has "Hidden Files and Folders",
    and I presume that's the one that makes AppData visible for easy navigation. Click Apply, and then Apply to Folders, so every bit of your disk can
    enjoy newfound "freedom" :-)

    Then, using Notepad, open the preferences.json and have a look around.


    With a prior version, the preferences.json file was present, but not in
    the latest version that I am using

    https://github.com/Steffenhir/GraXpert/releases/download/3.1.0rc1/graxpert-linux-amd64.zip

    I'm linking the Linux version because it has the same json files as used
    for Win and you don't actually have to install it to see all the files,
    just unzip. Several .json files are present and I looked them all over,
    but could not see anything about hardware acceleration in notepad.

    The only file indicating preferences is one called preferences.pyc which
    I read is non-editable unless using source code.

    The developers say they can be reached on something called Discord. I
    tried logging in and accessing them, but was met with password protected
    forums I was unable to access, but thought I could since I signed up. I
    had never heard of Discord, but it looks like something gamers uses.

    If you have any further ideas, thanks in advance, but it looks like I'm
    just going to have to stick with the Linux version until they provide a
    way to disable in the program files somewhere or some other alternative.




    I would not expect anyone to document at that level, so that's
    about as close as I can get you to the hardware acceleration entry.
    It might be in there, but I would not be able to tell otherwise,
    without installing it.

    You may comment "what a strange place to put a file". I suspect this
    is the C:\Program Files bypass. If a Dev started development in the
    WinXP era, some of them would store your Preferences file in the
    Program Files folder. This folder is owned by TrustedInstaller now.
    A user does not have editing rights for stuff in that folder.
    It could be, for example C:\Program Files\GraXpert where the developer
    stored the "preferences.json". Yet, the OS actually stored such
    materials in a deflection folder. The AppData folder above, the "username" account owns the file. This means editing in Notepad, stands
    a chance of working in there.

    Best Guess,
    Paul


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to Jackson Durmott on Wed Nov 20 22:00:15 2024
    On Wed, 11/20/2024 2:50 PM, Jackson Durmott wrote:


    With a prior version, the preferences.json file was present, but not in the latest version that I am using

    https://github.com/Steffenhir/GraXpert/releases/download/3.1.0rc1/graxpert-linux-amd64.zip

    I'm linking the Linux version because it has the same json files as used for Win and you don't actually have to install it to see all the files, just unzip.  Several .json files are present and I looked them all over, but could not see anything about
    hardware acceleration in notepad.

    The only file indicating preferences is one called preferences.pyc which I read is non-editable unless using source code.

    The developers say they can be reached on something called Discord.  I tried logging in and accessing them, but was met with password protected forums I was unable to access, but thought I could since I signed up.  I had never heard of Discord, but
    it looks like something gamers uses.

    If you have any further ideas, thanks in advance, but it looks like I'm just going to have to stick with the Linux version until they provide a way to disable in the program files somewhere or some other alternative.


    On turned the preference on and off, and checked Preferences.json and that
    is where it is recorded. The Preferences.json are written out when the
    program exits. I checked the preferences file twice, and could see true and false near the end of the file. Be careful not to upset the character
    set of the file and such, as the modern Notepad is not ANSI-only any more.

    [Picture]

    https://i.postimg.cc/HLDHg4fj/Graxpert-Windows-Preferences.gif

    Maybe you could do a general "grep" of the machine in Linux and see if
    you can spot that string.

    Linux had a claim once that it had an ETW-like subsystem so you could
    trace with a program similar to Process Monitor. But that may require a
    custom compilation of the kernel, and I've never seen any "promotion"
    articles showing screenshots of such a thing working.

    The reason for me including a Task Manager shot, is to show that
    while you can see some spikes in the GPU tab plot, those spikes are
    from Task Manager itself rendering. The GraXpert does not give me
    a strong feeling that the viewing window is accelerated, so the
    control pane should be able to come up. The slider for acceleration
    is for NN on CUDA, as near as I can tell. That's the button in the
    lower right corner of Advanced. The program should really be able
    to start, without crashing, and simply disable some NN function in
    response to a lack of horsepower.

    Linux isn't always accelerated. It has MESA for software fallback,
    which is quite good at hiding that it is the solution at the moment.
    On a computer with a 5GHz processor, you can be fooled into thinking
    OpenGL in Linux, is running on the video card, when it might be
    Nouveau and MESA.

    However, the NN acceleration and the CUDA checks, they are likely
    harder to fake, as there's no fallback for CUDA. OpenCL can run
    on CPU or GPU, but the program isn't coded in OpenCL. NVidia CUDA
    is just hardware, so it's either available or not-available.
    I can't say I've got a lot of usage out of it in Linux, as
    a lot of programs lack the code to get the GPU working (the distros
    do have packages that you can install, so the *system* is ready
    for CUDA, but the typical application is not so good at it.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jackson Durmott@21:1/5 to All on Thu Nov 21 00:04:18 2024
    T24gMTEvMjAvMjQgMTA6MDAgUE0sIFBhdWwgd3JvdGU6DQo+IE9uIFdlZCwgMTEvMjAvMjAy NCAyOjUwIFBNLCBKYWNrc29uIER1cm1vdHQgd3JvdGU6DQo+IA0KPj4NCj4+IFdpdGggYSBw cmlvciB2ZXJzaW9uLCB0aGUgcHJlZmVyZW5jZXMuanNvbiBmaWxlIHdhcyBwcmVzZW50LCBi dXQgbm90IGluIHRoZSBsYXRlc3QgdmVyc2lvbiB0aGF0IEkgYW0gdXNpbmcNCj4+DQo+PiBo dHRwczovL2dpdGh1Yi5jb20vU3RlZmZlbmhpci9HcmFYcGVydC9yZWxlYXNlcy9kb3dubG9h ZC8zLjEuMHJjMS9ncmF4cGVydC1saW51eC1hbWQ2NC56aXANCj4+DQo+PiBJJ20gbGlua2lu ZyB0aGUgTGludXggdmVyc2lvbiBiZWNhdXNlIGl0IGhhcyB0aGUgc2FtZSBqc29uIGZpbGVz IGFzIHVzZWQgZm9yIFdpbiBhbmQgeW91IGRvbid0IGFjdHVhbGx5IGhhdmUgdG8gaW5zdGFs bCBpdCB0byBzZWUgYWxsIHRoZSBmaWxlcywganVzdCB1bnppcC7CoCBTZXZlcmFsIC5qc29u IGZpbGVzIGFyZSBwcmVzZW50IGFuZCBJIGxvb2tlZCB0aGVtIGFsbCBvdmVyLCBidXQgY291 bGQgbm90IHNlZSBhbnl0aGluZyBhYm91dCBoYXJkd2FyZSBhY2NlbGVyYXRpb24gaW4gbm90 ZXBhZC4NCj4+DQo+PiBUaGUgb25seSBmaWxlIGluZGljYXRpbmcgcHJlZmVyZW5jZXMgaXMg b25lIGNhbGxlZCBwcmVmZXJlbmNlcy5weWMgd2hpY2ggSSByZWFkIGlzIG5vbi1lZGl0YWJs ZSB1bmxlc3MgdXNpbmcgc291cmNlIGNvZGUuDQo+Pg0KPj4gVGhlIGRldmVsb3BlcnMgc2F5 IHRoZXkgY2FuIGJlIHJlYWNoZWQgb24gc29tZXRoaW5nIGNhbGxlZCBEaXNjb3JkLsKgIEkg dHJpZWQgbG9nZ2luZyBpbiBhbmQgYWNjZXNzaW5nIHRoZW0sIGJ1dCB3YXMgbWV0IHdpdGgg cGFzc3dvcmQgcHJvdGVjdGVkIGZvcnVtcyBJIHdhcyB1bmFibGUgdG8gYWNjZXNzLCBidXQg dGhvdWdodCBJIGNvdWxkIHNpbmNlIEkgc2lnbmVkIHVwLsKgIEkgaGFkIG5ldmVyIGhlYXJk IG9mIERpc2NvcmQsIGJ1dCBpdCBsb29rcyBsaWtlIHNvbWV0aGluZyBnYW1lcnMgdXNlcy4N Cj4+DQo+PiBJZiB5b3UgaGF2ZSBhbnkgZnVydGhlciBpZGVhcywgdGhhbmtzIGluIGFkdmFu Y2UsIGJ1dCBpdCBsb29rcyBsaWtlIEknbSBqdXN0IGdvaW5nIHRvIGhhdmUgdG8gc3RpY2sg d2l0aCB0aGUgTGludXggdmVyc2lvbiB1bnRpbCB0aGV5IHByb3ZpZGUgYSB3YXkgdG8gZGlz YWJsZSBpbiB0aGUgcHJvZ3JhbSBmaWxlcyBzb21ld2hlcmUgb3Igc29tZSBvdGhlciBhbHRl cm5hdGl2ZS4NCj4+DQo+IA0KPiBPbiB0dXJuZWQgdGhlIHByZWZlcmVuY2Ugb24gYW5kIG9m ZiwgYW5kIGNoZWNrZWQgUHJlZmVyZW5jZXMuanNvbiBhbmQgdGhhdA0KPiBpcyB3aGVyZSBp dCBpcyByZWNvcmRlZC4gVGhlIFByZWZlcmVuY2VzLmpzb24gYXJlIHdyaXR0ZW4gb3V0IHdo ZW4gdGhlDQo+IHByb2dyYW0gZXhpdHMuIEkgY2hlY2tlZCB0aGUgcHJlZmVyZW5jZXMgZmls ZSB0d2ljZSwgYW5kIGNvdWxkIHNlZSB0cnVlIGFuZA0KPiBmYWxzZSBuZWFyIHRoZSBlbmQg b2YgdGhlIGZpbGUuIEJlIGNhcmVmdWwgbm90IHRvIHVwc2V0IHRoZSBjaGFyYWN0ZXINCj4g c2V0IG9mIHRoZSBmaWxlIGFuZCBzdWNoLCBhcyB0aGUgbW9kZXJuIE5vdGVwYWQgaXMgbm90 IEFOU0ktb25seSBhbnkgbW9yZS4NCj4gDQo+ICAgICBbUGljdHVyZV0NCj4gDQo+ICAgICAg aHR0cHM6Ly9pLnBvc3RpbWcuY2MvSExESGc0ZmovR3JheHBlcnQtV2luZG93cy1QcmVmZXJl bmNlcy5naWYNCg0KVGhhbmtzIGZvciB0aGUgaW1hZ2UuICBUaGF0IHByZWZlcmVuY2VzIGZp bGUgYW5kIGluZGVlZCB0aGF0IGZvbGRlciBhcmUgDQptaXNzaW5nIG9uIG15IG1hY2hpbmUg cHJvYmFibHkgYmVjYXVzZSwgYXMgeW91IHNheSwgaXQgaXMgbm90IGNyZWF0ZWQgDQp1bnRp bCBleGl0IGFuZCBzaW5jZSBJIGNvdWxkbid0IGdldCB0aGUgcHJvZ3JhbSB0byBzdGFydCB1 cC4uLi4NCg0KV2VsbCwgSSBkaWQgdHJ5IHNvbWV0aGluZy4gIEkgY3JlYXRlZCB0aGUgZG91 YmxlIEdyYVhwZXJ0IGZvbGRlciBpbiB0aGUgDQpzYW1lIGxvY2F0aW9uLCB0aGVuIGRpZCBh biBpbWFnZSB0byB0ZXh0IHRyYW5zZm9ybSwgY29waWVkIHRoZSByZXN1bHRpbmcgDQp0ZXh0 IGludG8gYSBibGFuayBub3RlcGFkLCBjaGFuZ2luZyB1c2VyIG5hbWUgYW5kIHRoZSBhY2Nl bGVyYXRpb24gDQpwcmVmZXJlbmNlIHRvIGZhbHNlLCB0aGVuIHNhdmVkIGFzIHByZWZlcmVu Y2VzLmpzb24gaW4gdGhlIEdyYVhwZXJ0IA0KZm9sZGVyLiBXaGVuIEkgdHJpZWQgc3RhcnRp bmcgR3JhWHBlcnQsIGhvd2V2ZXIsIHNhbWUgZXJyb3I6DQoNCmh0dHBzOi8vdGlueXVybC5j b20vNjg2OTRmN3ANCg0KDQo+IA0KPiBNYXliZSB5b3UgY291bGQgZG8gYSBnZW5lcmFsICJn cmVwIiBvZiB0aGUgbWFjaGluZSBpbiBMaW51eCBhbmQgc2VlIGlmDQo+IHlvdSBjYW4gc3Bv dCB0aGF0IHN0cmluZy4NCj4gDQo+IExpbnV4IGhhZCBhIGNsYWltIG9uY2UgdGhhdCBpdCBo YWQgYW4gRVRXLWxpa2Ugc3Vic3lzdGVtIHNvIHlvdSBjb3VsZA0KPiB0cmFjZSB3aXRoIGEg cHJvZ3JhbSBzaW1pbGFyIHRvIFByb2Nlc3MgTW9uaXRvci4gQnV0IHRoYXQgbWF5IHJlcXVp cmUgYQ0KPiBjdXN0b20gY29tcGlsYXRpb24gb2YgdGhlIGtlcm5lbCwgYW5kIEkndmUgbmV2 ZXIgc2VlbiBhbnkgInByb21vdGlvbiINCj4gYXJ0aWNsZXMgc2hvd2luZyBzY3JlZW5zaG90 cyBvZiBzdWNoIGEgdGhpbmcgd29ya2luZy4NCj4gDQo+IFRoZSByZWFzb24gZm9yIG1lIGlu Y2x1ZGluZyBhIFRhc2sgTWFuYWdlciBzaG90LCBpcyB0byBzaG93IHRoYXQNCj4gd2hpbGUg eW91IGNhbiBzZWUgc29tZSBzcGlrZXMgaW4gdGhlIEdQVSB0YWIgcGxvdCwgdGhvc2Ugc3Bp a2VzIGFyZQ0KPiBmcm9tIFRhc2sgTWFuYWdlciBpdHNlbGYgcmVuZGVyaW5nLiBUaGUgR3Jh WHBlcnQgZG9lcyBub3QgZ2l2ZSBtZQ0KPiBhIHN0cm9uZyBmZWVsaW5nIHRoYXQgdGhlIHZp ZXdpbmcgd2luZG93IGlzIGFjY2VsZXJhdGVkLCBzbyB0aGUNCj4gY29udHJvbCBwYW5lIHNo b3VsZCBiZSBhYmxlIHRvIGNvbWUgdXAuIFRoZSBzbGlkZXIgZm9yIGFjY2VsZXJhdGlvbg0K PiBpcyBmb3IgTk4gb24gQ1VEQSwgYXMgbmVhciBhcyBJIGNhbiB0ZWxsLiBUaGF0J3MgdGhl IGJ1dHRvbiBpbiB0aGUNCj4gbG93ZXIgcmlnaHQgY29ybmVyIG9mIEFkdmFuY2VkLiBUaGUg cHJvZ3JhbSBzaG91bGQgcmVhbGx5IGJlIGFibGUNCj4gdG8gc3RhcnQsIHdpdGhvdXQgY3Jh c2hpbmcsIGFuZCBzaW1wbHkgZGlzYWJsZSBzb21lIE5OIGZ1bmN0aW9uIGluDQo+IHJlc3Bv bnNlIHRvIGEgbGFjayBvZiBob3JzZXBvd2VyLg0KPiANCj4gTGludXggaXNuJ3QgYWx3YXlz IGFjY2VsZXJhdGVkLiBJdCBoYXMgTUVTQSBmb3Igc29mdHdhcmUgZmFsbGJhY2ssDQo+IHdo aWNoIGlzIHF1aXRlIGdvb2QgYXQgaGlkaW5nIHRoYXQgaXQgaXMgdGhlIHNvbHV0aW9uIGF0 IHRoZSBtb21lbnQuDQo+IE9uIGEgY29tcHV0ZXIgd2l0aCBhIDVHSHogcHJvY2Vzc29yLCB5 b3UgY2FuIGJlIGZvb2xlZCBpbnRvIHRoaW5raW5nDQo+IE9wZW5HTCBpbiBMaW51eCwgaXMg cnVubmluZyBvbiB0aGUgdmlkZW8gY2FyZCwgd2hlbiBpdCBtaWdodCBiZQ0KPiBOb3V2ZWF1 IGFuZCBNRVNBLg0KPiANCj4gSG93ZXZlciwgdGhlIE5OIGFjY2VsZXJhdGlvbiBhbmQgdGhl IENVREEgY2hlY2tzLCB0aGV5IGFyZSBsaWtlbHkNCj4gaGFyZGVyIHRvIGZha2UsIGFzIHRo ZXJlJ3Mgbm8gZmFsbGJhY2sgZm9yIENVREEuIE9wZW5DTCBjYW4gcnVuDQo+IG9uIENQVSBv ciBHUFUsIGJ1dCB0aGUgcHJvZ3JhbSBpc24ndCBjb2RlZCBpbiBPcGVuQ0wuIE5WaWRpYSBD VURBDQo+IGlzIGp1c3QgaGFyZHdhcmUsIHNvIGl0J3MgZWl0aGVyIGF2YWlsYWJsZSBvciBu b3QtYXZhaWxhYmxlLg0KPiBJIGNhbid0IHNheSBJJ3ZlIGdvdCBhIGxvdCBvZiB1c2FnZSBv dXQgb2YgaXQgaW4gTGludXgsIGFzDQo+IGEgbG90IG9mIHByb2dyYW1zIGxhY2sgdGhlIGNv ZGUgdG8gZ2V0IHRoZSBHUFUgd29ya2luZyAodGhlIGRpc3Ryb3MNCj4gZG8gaGF2ZSBwYWNr YWdlcyB0aGF0IHlvdSBjYW4gaW5zdGFsbCwgc28gdGhlICpzeXN0ZW0qIGlzIHJlYWR5DQo+ IGZvciBDVURBLCBidXQgdGhlIHR5cGljYWwgYXBwbGljYXRpb24gaXMgbm90IHNvIGdvb2Qg YXQgaXQuDQo+IA0KPiAgICAgUGF1bA0KDQo=

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jackson Durmott@21:1/5 to All on Thu Nov 21 01:04:27 2024
    T24gMTEvMjEvMjQgMTI6MzkgQU0sIFBhdWwgd3JvdGU6DQo+IE9uIFRodSwgMTEvMjEvMjAy NCAxMjowNCBBTSwgSmFja3NvbiBEdXJtb3R0IHdyb3RlOg0KPiANCj4+PiAgwqDCoMKgwqAg aHR0cHM6Ly9pLnBvc3RpbWcuY2MvSExESGc0ZmovR3JheHBlcnQtV2luZG93cy1QcmVmZXJl bmNlcy5naWYNCj4+DQo+PiBUaGFua3MgZm9yIHRoZSBpbWFnZS7CoCBUaGF0IHByZWZlcmVu Y2VzIGZpbGUgYW5kIGluZGVlZCB0aGF0IGZvbGRlciBhcmUgbWlzc2luZyBvbiBteSBtYWNo aW5lIHByb2JhYmx5IGJlY2F1c2UsIGFzIHlvdSBzYXksIGl0IGlzIG5vdCBjcmVhdGVkIHVu dGlsIGV4aXQgYW5kIHNpbmNlIEkgY291bGRuJ3QgZ2V0IHRoZSBwcm9ncmFtIHRvIHN0YXJ0 IHVwLi4uLg0KPj4NCj4+IFdlbGwsIEkgZGlkIHRyeSBzb21ldGhpbmcuwqAgSSBjcmVhdGVk IHRoZSBkb3VibGUgR3JhWHBlcnQgZm9sZGVyIGluIHRoZSBzYW1lIGxvY2F0aW9uLCB0aGVu IGRpZCBhbiBpbWFnZSB0byB0ZXh0IHRyYW5zZm9ybSwgY29waWVkIHRoZSByZXN1bHRpbmcg dGV4dCBpbnRvIGEgYmxhbmsgbm90ZXBhZCwgY2hhbmdpbmcgdXNlciBuYW1lIGFuZCB0aGUg YWNjZWxlcmF0aW9uIHByZWZlcmVuY2UgdG8gZmFsc2UsIHRoZW4gc2F2ZWQgYXMgcHJlZmVy ZW5jZXMuanNvbiBpbiB0aGUgR3JhWHBlcnQgZm9sZGVyLiBXaGVuIEkgdHJpZWQgc3RhcnRp bmcgR3JhWHBlcnQsIGhvd2V2ZXIsIHNhbWUgZXJyb3I6DQo+Pg0KPj4gaHR0cHM6Ly90aW55 dXJsLmNvbS82ODY5NGY3cA0KPiANCj4gSSdtIGdldHRpbmcgYSBibGFuayB3aW5kb3cgb24g dGhhdCBUaW55VVJMIGluIEZpcmVmb3MuDQo+IEluIE1TRWRnZSwgSSBnZXQ6DQo+IA0KPiAg ICAgIlRoaXMgcHJpdmF0ZS11c2VyLWltYWdlcy5naXRodWJ1c2VyY29udGVudC5jb20gcGFn ZSBjYW7igJl0IGJlIGZvdW5kIg0KPiANCj4gICAgIFBhdWwNCg0KVHJ5IHRoaXMgb25lOg0K DQpodHRwczovL2liYi5jby9Wd3d2eDM0DQoNCg==

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to Jackson Durmott on Thu Nov 21 00:39:57 2024
    On Thu, 11/21/2024 12:04 AM, Jackson Durmott wrote:

         https://i.postimg.cc/HLDHg4fj/Graxpert-Windows-Preferences.gif

    Thanks for the image.  That preferences file and indeed that folder are missing on my machine probably because, as you say, it is not created until exit and since I couldn't get the program to start up....

    Well, I did try something.  I created the double GraXpert folder in the same location, then did an image to text transform, copied the resulting text into a blank notepad, changing user name and the acceleration preference to false, then saved as
    preferences.json in the GraXpert folder. When I tried starting GraXpert, however, same error:

    https://tinyurl.com/68694f7p

    I'm getting a blank window on that TinyURL in Firefos.
    In MSEdge, I get:

    "This private-user-images.githubusercontent.com page can’t be found"

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to Jackson Durmott on Thu Nov 21 07:13:01 2024
    On Thu, 11/21/2024 1:04 AM, Jackson Durmott wrote:
    On 11/21/24 12:39 AM, Paul wrote:
    On Thu, 11/21/2024 12:04 AM, Jackson Durmott wrote:

          https://i.postimg.cc/HLDHg4fj/Graxpert-Windows-Preferences.gif >>>
    Thanks for the image.  That preferences file and indeed that folder are missing on my machine probably because, as you say, it is not created until exit and since I couldn't get the program to start up....

    Well, I did try something.  I created the double GraXpert folder in the same location, then did an image to text transform, copied the resulting text into a blank notepad, changing user name and the acceleration preference to false, then saved as
    preferences.json in the GraXpert folder. When I tried starting GraXpert, however, same error:

    https://tinyurl.com/68694f7p

    I'm getting a blank window on that TinyURL in Firefos.
    In MSEdge, I get:

        "This private-user-images.githubusercontent.com page can’t be found"

        Paul

    Try this one:

    https://ibb.co/Vwwvx34


    How many astronomy software tools do you have ?

    First of all, see if you have a C:\hostedtoolcache

    Temporarily rename that, and run GraXPert again.

    I don't have one of those, and the GraXpert program starts here OK.
    I have no astronomy pollution on my C: drive, no collection of careless programs spewing libraries all over the place with abandon :-)

    In Process Monitor, I can see "astro.py" checking for a known
    path for some library, and maybe some other program has left
    the item in question in C:\hostedtoolcache and you've ended up
    "starting the wrong module" during path resolution.

    [Picture]

    https://i.postimg.cc/Fzrn7njK/graxpert-hostedtoolcache.gif

    I'm willing to bet, that your Process Monitor trace does not look
    like mine, because your copy of GraXpert is "walking down the C:\hostedtoolcache tree", which exists on your machine.
    And that path does not exist on my machine.

    That's why that error message picture of yours made no sense :-)
    I couldn't figure out where such a path came from, when I didn't
    have a path like that on my machine, and it looked like a path
    from a Dev machine. I mean, we see Dev pollution all the time
    inside binaries, but normally it is not "instantiated" pollution,
    the strings seen which hint at a Devs tree, nothing tries to walk
    those on our machines out here.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jackson Durmott@21:1/5 to Paul on Thu Nov 21 09:25:37 2024
    On 11/21/24 7:13 AM, Paul wrote:



    How many astronomy software tools do you have ?

    First of all, see if you have a C:\hostedtoolcache

    Temporarily rename that, and run GraXPert again.

    I have quite a few astronomy tools, but most are on a separate hard
    drive and are portable, not requiring installation. GraXpert was an
    exception, however, although it is self contained on Ubuntu.

    Well, I just searched and don't see that file/ folder on the C drive.


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to Jackson Durmott on Thu Nov 21 17:11:10 2024
    On Thu, 11/21/2024 9:25 AM, Jackson Durmott wrote:
    On 11/21/24 7:13 AM, Paul wrote:



    How many astronomy software tools do you have ?

    First of all, see if you have a C:\hostedtoolcache

    Temporarily rename that, and run GraXPert again.

    I have quite a few astronomy tools, but most are on a separate hard drive and are portable, not requiring installation.  GraXpert was an exception, however, although it is self contained on Ubuntu.

    Well, I just searched and don't see that file/ folder on the C drive.


    OK, in my picture, you can see GraXPert is "sniffing" a
    particular directory that I do not have.

    And in your picture, you can see the software claiming
    it is *starting* materials in C:\hosted... so it has
    located such a thing.

    C:
    cd \
    dir # Check for visible files
    dir /AH # Check for hidden files

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jackson Durmott@21:1/5 to All on Thu Nov 21 19:11:45 2024
    T24gMTEvMjEvMjQgNToxMSBQTSwgUGF1bCB3cm90ZToNCj4gT24gVGh1LCAxMS8yMS8yMDI0 IDk6MjUgQU0sIEphY2tzb24gRHVybW90dCB3cm90ZToNCj4+IE9uIDExLzIxLzI0IDc6MTMg QU0sIFBhdWwgd3JvdGU6DQo+Pg0KPj4+Pg0KPj4+DQo+Pj4gSG93IG1hbnkgYXN0cm9ub215 IHNvZnR3YXJlIHRvb2xzIGRvIHlvdSBoYXZlID8NCj4+Pg0KPj4+IEZpcnN0IG9mIGFsbCwg c2VlIGlmIHlvdSBoYXZlIGEgQzpcaG9zdGVkdG9vbGNhY2hlDQo+Pj4NCj4+PiBUZW1wb3Jh cmlseSByZW5hbWUgdGhhdCwgYW5kIHJ1biBHcmFYUGVydCBhZ2Fpbi4NCj4+DQo+PiBJIGhh dmUgcXVpdGUgYSBmZXcgYXN0cm9ub215IHRvb2xzLCBidXQgbW9zdCBhcmUgb24gYSBzZXBh cmF0ZSBoYXJkIGRyaXZlIGFuZCBhcmUgcG9ydGFibGUsIG5vdCByZXF1aXJpbmcgaW5zdGFs bGF0aW9uLsKgIEdyYVhwZXJ0IHdhcyBhbiBleGNlcHRpb24sIGhvd2V2ZXIsIGFsdGhvdWdo IGl0IGlzIHNlbGYgY29udGFpbmVkIG9uIFVidW50dS4NCj4+DQo+PiBXZWxsLCBJIGp1c3Qg c2VhcmNoZWQgYW5kIGRvbid0IHNlZSB0aGF0IGZpbGUvIGZvbGRlciBvbiB0aGUgQyBkcml2 ZS4NCj4+Pg0KPiANCj4gT0ssIGluIG15IHBpY3R1cmUsIHlvdSBjYW4gc2VlIEdyYVhQZXJ0 IGlzICJzbmlmZmluZyIgYQ0KPiBwYXJ0aWN1bGFyIGRpcmVjdG9yeSB0aGF0IEkgZG8gbm90 IGhhdmUuDQo+IA0KPiBBbmQgaW4geW91ciBwaWN0dXJlLCB5b3UgY2FuIHNlZSB0aGUgc29m dHdhcmUgY2xhaW1pbmcNCj4gaXQgaXMgKnN0YXJ0aW5nKiBtYXRlcmlhbHMgaW4gQzpcaG9z dGVkLi4uICBzbyBpdCBoYXMNCj4gbG9jYXRlZCBzdWNoIGEgdGhpbmcuDQoNClRoYXQncyB3 aGF0IEkgdGhvdWdodCBhcyB3ZWxsLiAgVGhlIGVycm9yIGJveCBzaG91bGRuJ3QgaGF2ZSBz YWlkIHdoYXQgDQppcyBoYXMgaWYgdGhlIGZpbGUvIGZvbGRlciB3YXMgbm90IHByZXNlbnQu ICBZb3UgbWVudGlvbmVkIGNoZWNraW5nIHRoZSANCmhpZGRlbiBmaWxlcyBvcHRpb24gaW4g V2luIGR1cmluZyBzZWFyY2hpbmcgYXQgb25lIHBvaW50IGFuZCBJIGhhdmUgaGFkIA0KdGhp cyBlbmFibGVkIGZvciB5ZWFycy4gIEkgd291bGQgaGF2ZSB0aG91Z2h0IG5vdCBoYXZpbmcg dGhlIGZpbGVzIA0KaGlkZGVuIHdvdWxkIGhhdmUgZm91bmQgaXQsIGJ1dCBldmlkZW50bHkg bm90Lg0KICAgPiBDOg0KPiBjZCBcDQo+IGRpciAgICAgICAgICAjIENoZWNrIGZvciB2aXNp YmxlIGZpbGVzDQo+IGRpciAvQUggICAgICAjIENoZWNrIGZvciBoaWRkZW4gZmlsZXMNCg0K T2ssIHdpbGwgcmV0cnkgd2l0aCB0aGUgYWJvdmUgYW5kIHJlcG9ydCBiYWNrLg0KDQo+ICAg ICBQYXVsDQoNCg==

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jackson Durmott@21:1/5 to All on Thu Nov 21 19:24:43 2024
    T24gMTEvMjEvMjQgNToxMSBQTSwgUGF1bCB3cm90ZToNCj4gT24gVGh1LCAxMS8yMS8yMDI0 IDk6MjUgQU0sIEphY2tzb24gRHVybW90dCB3cm90ZToNCj4+IE9uIDExLzIxLzI0IDc6MTMg QU0sIFBhdWwgd3JvdGU6DQo+Pg0KPj4+Pg0KPj4+DQo+Pj4gSG93IG1hbnkgYXN0cm9ub215 IHNvZnR3YXJlIHRvb2xzIGRvIHlvdSBoYXZlID8NCj4+Pg0KPj4+IEZpcnN0IG9mIGFsbCwg c2VlIGlmIHlvdSBoYXZlIGEgQzpcaG9zdGVkdG9vbGNhY2hlDQo+Pj4NCj4+PiBUZW1wb3Jh cmlseSByZW5hbWUgdGhhdCwgYW5kIHJ1biBHcmFYUGVydCBhZ2Fpbi4NCj4+DQo+PiBJIGhh dmUgcXVpdGUgYSBmZXcgYXN0cm9ub215IHRvb2xzLCBidXQgbW9zdCBhcmUgb24gYSBzZXBh cmF0ZSBoYXJkIGRyaXZlIGFuZCBhcmUgcG9ydGFibGUsIG5vdCByZXF1aXJpbmcgaW5zdGFs bGF0aW9uLsKgIEdyYVhwZXJ0IHdhcyBhbiBleGNlcHRpb24sIGhvd2V2ZXIsIGFsdGhvdWdo IGl0IGlzIHNlbGYgY29udGFpbmVkIG9uIFVidW50dS4NCj4+DQo+PiBXZWxsLCBJIGp1c3Qg c2VhcmNoZWQgYW5kIGRvbid0IHNlZSB0aGF0IGZpbGUvIGZvbGRlciBvbiB0aGUgQyBkcml2 ZS4NCj4+Pg0KPiANCj4gT0ssIGluIG15IHBpY3R1cmUsIHlvdSBjYW4gc2VlIEdyYVhQZXJ0 IGlzICJzbmlmZmluZyIgYQ0KPiBwYXJ0aWN1bGFyIGRpcmVjdG9yeSB0aGF0IEkgZG8gbm90 IGhhdmUuDQo+IA0KPiBBbmQgaW4geW91ciBwaWN0dXJlLCB5b3UgY2FuIHNlZSB0aGUgc29m dHdhcmUgY2xhaW1pbmcNCj4gaXQgaXMgKnN0YXJ0aW5nKiBtYXRlcmlhbHMgaW4gQzpcaG9z dGVkLi4uICBzbyBpdCBoYXMNCj4gbG9jYXRlZCBzdWNoIGEgdGhpbmcuDQo+IA0KPiBDOg0K PiBjZCBcDQo+IGRpciAgICAgICAgICAjIENoZWNrIGZvciB2aXNpYmxlIGZpbGVzDQo+IGRp ciAvQUggICAgICAjIENoZWNrIGZvciBoaWRkZW4gZmlsZXMNCj4gDQo+ICAgICBQYXVsDQoN Cmh0dHBzOi8vaWJiLmNvLzMwRlk0VFYNCg0KVGhlIGZpbGUgb3IgZm9sZGVyIGl0IGNsYWlt cyBpdCBpcyBmaW5kaW5nIGlzIG5vdCB0aGVyZS4NCg==

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to Jackson Durmott on Fri Nov 22 01:05:09 2024
    On Thu, 11/21/2024 7:24 PM, Jackson Durmott wrote:
    On 11/21/24 5:11 PM, Paul wrote:
    On Thu, 11/21/2024 9:25 AM, Jackson Durmott wrote:
    On 11/21/24 7:13 AM, Paul wrote:



    How many astronomy software tools do you have ?

    First of all, see if you have a C:\hostedtoolcache

    Temporarily rename that, and run GraXPert again.

    I have quite a few astronomy tools, but most are on a separate hard drive and are portable, not requiring installation.  GraXpert was an exception, however, although it is self contained on Ubuntu.

    Well, I just searched and don't see that file/ folder on the C drive.


    OK, in my picture, you can see GraXPert is "sniffing" a
    particular directory that I do not have.

    And in your picture, you can see the software claiming
    it is *starting* materials in C:\hosted...  so it has
    located such a thing.

    C:
    cd \
    dir          # Check for visible files
    dir /AH      # Check for hidden files

        Paul

    https://ibb.co/30FY4TV

    The file or folder it claims it is finding is not there.

    OK, the code lies about the path the module comes from.
    Some of these paths, are the hardwired paths on the developer machine.
    Only the name of the routine on the end makes sense.

    ****** Your error message trace (via Snippingtool OCR) *******

    cx_Freeze: Python error in main script

    Traceback (most recent call last):
    File "C:\hostedtoolcache\windows\Python\3.10.11\x64\Lib\
    site-packages\cx_Freeze\initscripts\ __ startup __. py", line 138, in run
    File "C:\hostedtoolcache\windows\Python\3.10.11\x64\Lib\
    site-packages\cx_Freeze\initscripts\console.py", line 17, in run
    File "graxpert\main.py", line 18, in <module>
    File "D:\a\GraXpert\GraXpert\graxpert\ai_model_handling.py', line 7, in <module>
    File "C:\hostedtoolcache\windows\Python\3.10.11\x64\lib\
    site-packages\onnxruntime\ __ init _. py", line 57, in <module>
    File "C:\hostedtoolcache\windows\Python\3.10.11\x64\lib\
    site-packages\onnxruntime\ __ init _. py", line 23, in <module>
    File "C:\hostedtoolcache\windows\Python\3.10.11\x64\lib\
    site-packages\onnxruntime\capi\_pybind_state.py", line 32, in <module> ImportError: DLL load failed while importing
    onnxruntime_pybind11_state: The specified module could not be found.

    ***************************************

    The folder involved, is an onnx capi (Capability) folder. I unpacked
    the MSI to make a folder on this machine (not my Test Machine).

    Name: graxpert-windows-amd64-3.1.0rc1.msi
    Size: 176,394,240 bytes (168 MiB)
    SHA256: B34D4A5AC9FBED53471895D806F28FA399BFBD0A7315291D5ED761CB95010CD8

    K:\TEMP\lib\onnxruntime\capi>dir

    Thu, 11/21/2024 11:04 PM <DIR> .
    Thu, 11/21/2024 11:04 PM <DIR> ..
    Sun, 11/10/2024 01:37 PM 18,527,280 DirectML.dll
    Sun, 11/10/2024 01:37 PM 18,276,896 onnxruntime.dll
    Sun, 11/10/2024 01:37 PM 21,544 onnxruntime_providers_shared.dll

    Sun, 11/10/2024 01:38 PM 2,211 onnxruntime_collect_build_info.pyc Sun, 11/10/2024 01:38 PM 59,216 onnxruntime_inference_collection.pyc
    Sun, 11/10/2024 01:37 PM 22,438,944 onnxruntime_pybind11_state.pyd <=== May actually be a DLL, hard to say
    Sun, 11/10/2024 01:38 PM 5,977 onnxruntime_validation.pyc
    Sun, 11/10/2024 01:38 PM 232 version_info.pyc
    Sun, 11/10/2024 01:38 PM 203 _ld_preload.pyc
    Sun, 11/10/2024 01:38 PM 1,336 _pybind_state.pyc
    Sun, 11/10/2024 01:38 PM 200 __init__.pyc

    $ file onnxruntime_pybind11_state.pyd
    onnxruntime_pybind11_state.pyd: PE32+ executable (DLL) (console) x86-64, for MS Windows

    $ file onnxruntime_inference_collection.pyc onnxruntime_inference_collection.pyc: data <=== strange it does not mention PE32.

    notepad onnxruntime_pybind11_state.pyd

    onnxruntime_pybind11_state initialization failed 1.20.0
    ORT Build Info: git-branch=HEAD, git-commit-id=c4fb724e81, build type=Release,
    cmake cxx flags: /MP /guard:cf /DWIN32 /D_WINDOWS /D_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR
    /DWINAPI_FAMILY=100 /DWINVER=0x0A00 /D_WIN32_WINNT=0x0A00 /DNTDDI_VERSION=0x0A000000
    /Qspectre /DONNXRUNTIME_ENABLE_INTEL_METEOR_LAKE_MOBILE_PLATFORM_PERF_PATCH /O2 /Ob2
    /DNDEBUG /Zc:__cplusplus /EHsc /wd26812 -DEIGEN_HAS_C99_MATH -DCPUINFO_SUPPORTED

    Return list of available Execution Providers in this installed version of Onnxruntime. The order of
    elements represents the default priority order of Execution Providers from highest to lowest.

    get_available_providers
    get_version_string
    get_build_info
    has_collective_ops

    It could be, that it has some elements of Python in it, but it could have regular C++ or C# libraries from Microsoft bound into it. I just can't keep
    up with these guys and their "anything goes" mixing of executables now :-/

    onnxruntime_providers_cuda.dll <=== NVidia onnxruntime_providers_cuda_ut.dll
    onnxruntime_providers_cann.dll
    onnxruntime_providers_rocm.dll <=== AMD
    onnxruntime_providers_dnnl.dll
    onnxruntime_providers_vitisai.dll
    onnxruntime_providers_openvino.dll <=== Intel onnxruntime_providers_tensorrt.dll
    onnxruntime_providers_migraphx.dll

    *******

    Our breadcrumb then, is

    onnxruntime_pybind11_state.pyd DLL load failed while importing

    Not very helpful entry. No response. A second link like this was the
    same way, an entry, no response.

    https://github.com/microsoft/onnxruntime/issues/16116

    They mention checking the .pyd with dumpbin. But likely the dumpbin
    would need to be in the path to work (you might need the whole folder
    that dumpbin.exe is in, as dumpbin might be using some DLLs).

    https://stackoverflow.com/questions/20201868/importerror-dll-load-failed-the-specified-module-could-not-be-found

    Note the series of api_ DLL files at the top level of the install.
    Sets of these are used per OS version. Firefox.exe for example, has
    a "proper set" and demonstrates to developers, now you're supposed to do
    it. I frequently find half-baked sets of those wrapper DLLs included
    in executables. At one time, Microsoft tried to distribute those
    at the system-wide level. But they might not be doing that with the
    same gusto as before. What the api_ name allows, is linking to the correct
    DLL when the executable is at runtime state (you figure out your actual
    DLLs as the program loads and runs).

    In a Command Prompt as an ordinary user:

    H:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.30.30705\bin\Hostx64\x64>.\dumpbin
    /dependents D:\TEMP\lib\onnxruntime\capi\onnxruntime_pybind11_state.pyd

    Image has the following dependencies:

    python311.dll
    DirectML.dll
    d3d12.dll
    dxgi.dll
    dxcore.dll
    KERNEL32.dll
    ADVAPI32.dll
    api-ms-win-core-path-l1-1-0.dll
    MSVCP140.dll
    MSVCP140_1.dll
    VCRUNTIME140.dll
    VCRUNTIME140_1.dll
    api-ms-win-crt-runtime-l1-1-0.dll
    api-ms-win-crt-heap-l1-1-0.dll
    api-ms-win-crt-string-l1-1-0.dll
    api-ms-win-crt-math-l1-1-0.dll
    api-ms-win-crt-stdio-l1-1-0.dll
    api-ms-win-crt-filesystem-l1-1-0.dll
    api-ms-win-crt-convert-l1-1-0.dll
    api-ms-win-crt-time-l1-1-0.dll
    api-ms-win-crt-locale-l1-1-0.dll

    Checking the main GraXpert folder, it has those api-* mapping DLL entries. Mapping DLLs have a small size and a minimal structure. They should not
    be large files. Notice that VC Runtime libraries are in the folder too.
    To buttress those, you can get a multi-version VC package. Like,
    I don't like the look of the "VCRUNTIME140_1.dll" entry, that looks
    reckless.

    Install the x86 and x674 from here, to fill your system folder with

    https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170

    "Visual Studio 2015, 2017, 2019, and 2022 runtimes"

    The VCRUNTIME140_1.dll might well be a Visual Studio 2015 item.

    It's my uninformed opinion right now, that this code has plenty
    of defensive coding, and it should be able to tell that your old
    AMD card does not match any of the DirectML (Machine Learning) type
    hardwares, such as ROCM. To get decent hardware, is going
    to be $500 plus. To get a recent CUDA or a ROCM that is up to date
    and ready for anything. It's not just any old CUDA either, a bit
    disingenuous if you ask me. I can't see how they cannot angle
    for at least a RTX4060 for this, at NVidia headquarters :-)
    Owning am RTX4090 would only go faster.

    This code should also be able to run on a CPU, but then we don't
    know if the CPU has to have Population Count instruction (POPCNT)
    or SSE 4.2 for example. Life is filled with uncertainty.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jackson Durmott@21:1/5 to All on Fri Nov 22 15:56:49 2024
    T24gMTEvMjIvMjQgMTowNSBBTSwgUGF1bCB3cm90ZToNCj4gT24gVGh1LCAxMS8yMS8yMDI0 IDc6MjQgUE0sIEphY2tzb24gRHVybW90dCB3cm90ZToNCj4+IE9uIDExLzIxLzI0IDU6MTEg UE0sIFBhdWwgd3JvdGU6DQo+Pj4gT24gVGh1LCAxMS8yMS8yMDI0IDk6MjUgQU0sIEphY2tz b24gRHVybW90dCB3cm90ZToNCj4+Pj4gT24gMTEvMjEvMjQgNzoxMyBBTSwgUGF1bCB3cm90 ZToNCj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IEhvdyBtYW55IGFzdHJvbm9teSBzb2Z0 d2FyZSB0b29scyBkbyB5b3UgaGF2ZSA/DQo+Pj4+Pg0KPj4+Pj4gRmlyc3Qgb2YgYWxsLCBz ZWUgaWYgeW91IGhhdmUgYSBDOlxob3N0ZWR0b29sY2FjaGUNCj4+Pj4+DQo+Pj4+PiBUZW1w b3JhcmlseSByZW5hbWUgdGhhdCwgYW5kIHJ1biBHcmFYUGVydCBhZ2Fpbi4NCj4+Pj4NCj4+ Pj4gSSBoYXZlIHF1aXRlIGEgZmV3IGFzdHJvbm9teSB0b29scywgYnV0IG1vc3QgYXJlIG9u IGEgc2VwYXJhdGUgaGFyZCBkcml2ZSBhbmQgYXJlIHBvcnRhYmxlLCBub3QgcmVxdWlyaW5n IGluc3RhbGxhdGlvbi7CoCBHcmFYcGVydCB3YXMgYW4gZXhjZXB0aW9uLCBob3dldmVyLCBh bHRob3VnaCBpdCBpcyBzZWxmIGNvbnRhaW5lZCBvbiBVYnVudHUuDQo+Pj4+DQo+Pj4+IFdl bGwsIEkganVzdCBzZWFyY2hlZCBhbmQgZG9uJ3Qgc2VlIHRoYXQgZmlsZS8gZm9sZGVyIG9u IHRoZSBDIGRyaXZlLg0KPj4+Pj4NCj4+Pg0KPj4+IE9LLCBpbiBteSBwaWN0dXJlLCB5b3Ug Y2FuIHNlZSBHcmFYUGVydCBpcyAic25pZmZpbmciIGENCj4+PiBwYXJ0aWN1bGFyIGRpcmVj dG9yeSB0aGF0IEkgZG8gbm90IGhhdmUuDQo+Pj4NCj4+PiBBbmQgaW4geW91ciBwaWN0dXJl LCB5b3UgY2FuIHNlZSB0aGUgc29mdHdhcmUgY2xhaW1pbmcNCj4+PiBpdCBpcyAqc3RhcnRp bmcqIG1hdGVyaWFscyBpbiBDOlxob3N0ZWQuLi7CoCBzbyBpdCBoYXMNCj4+PiBsb2NhdGVk IHN1Y2ggYSB0aGluZy4NCj4+Pg0KPj4+IEM6DQo+Pj4gY2QgXA0KPj4+IGRpcsKgwqDCoMKg wqDCoMKgwqDCoCAjIENoZWNrIGZvciB2aXNpYmxlIGZpbGVzDQo+Pj4gZGlyIC9BSMKgwqDC oMKgwqAgIyBDaGVjayBmb3IgaGlkZGVuIGZpbGVzDQo+Pj4NCj4+PiAgwqDCoMKgIFBhdWwN Cj4+DQo+PiBodHRwczovL2liYi5jby8zMEZZNFRWDQo+Pg0KPj4gVGhlIGZpbGUgb3IgZm9s ZGVyIGl0IGNsYWltcyBpdCBpcyBmaW5kaW5nIGlzIG5vdCB0aGVyZS4NCj4gDQo+IE9LLCB0 aGUgY29kZSBsaWVzIGFib3V0IHRoZSBwYXRoIHRoZSBtb2R1bGUgY29tZXMgZnJvbS4NCj4g U29tZSBvZiB0aGVzZSBwYXRocywgYXJlIHRoZSBoYXJkd2lyZWQgcGF0aHMgb24gdGhlIGRl dmVsb3BlciBtYWNoaW5lLg0KPiBPbmx5IHRoZSBuYW1lIG9mIHRoZSByb3V0aW5lIG9uIHRo ZSBlbmQgbWFrZXMgc2Vuc2UuDQo+IA0KPiAqKioqKiogWW91ciBlcnJvciBtZXNzYWdlIHRy YWNlICh2aWEgU25pcHBpbmd0b29sIE9DUikgKioqKioqKg0KPiANCj4gY3hfRnJlZXplOiBQ eXRob24gZXJyb3IgaW4gbWFpbiBzY3JpcHQNCj4gDQo+IFRyYWNlYmFjayAobW9zdCByZWNl bnQgY2FsbCBsYXN0KToNCj4gRmlsZSAiQzpcaG9zdGVkdG9vbGNhY2hlXHdpbmRvd3NcUHl0 aG9uXDMuMTAuMTFceDY0XExpYlwNCj4gICAgICAgICAgIHNpdGUtcGFja2FnZXNcY3hfRnJl ZXplXGluaXRzY3JpcHRzXCBfXyBzdGFydHVwIF9fLiBweSIsIGxpbmUgMTM4LCBpbiBydW4N Cj4gRmlsZSAiQzpcaG9zdGVkdG9vbGNhY2hlXHdpbmRvd3NcUHl0aG9uXDMuMTAuMTFceDY0 XExpYlwNCj4gICAgICAgICAgIHNpdGUtcGFja2FnZXNcY3hfRnJlZXplXGluaXRzY3JpcHRz XGNvbnNvbGUucHkiLCBsaW5lIDE3LCBpbiBydW4NCj4gRmlsZSAiZ3JheHBlcnRcbWFpbi5w eSIsIGxpbmUgMTgsIGluIDxtb2R1bGU+DQo+IEZpbGUgIkQ6XGFcR3JhWHBlcnRcR3JhWHBl cnRcZ3JheHBlcnRcYWlfbW9kZWxfaGFuZGxpbmcucHknLCBsaW5lIDcsIGluIDxtb2R1bGU+ DQo+IEZpbGUgIkM6XGhvc3RlZHRvb2xjYWNoZVx3aW5kb3dzXFB5dGhvblwzLjEwLjExXHg2 NFxsaWJcDQo+ICAgICAgICAgICBzaXRlLXBhY2thZ2VzXG9ubnhydW50aW1lXCBfXyBpbml0 IF8uIHB5IiwgbGluZSA1NywgaW4gPG1vZHVsZT4NCj4gRmlsZSAiQzpcaG9zdGVkdG9vbGNh Y2hlXHdpbmRvd3NcUHl0aG9uXDMuMTAuMTFceDY0XGxpYlwNCj4gICAgICAgICAgIHNpdGUt cGFja2FnZXNcb25ueHJ1bnRpbWVcIF9fIGluaXQgXy4gcHkiLCBsaW5lIDIzLCBpbiA8bW9k dWxlPg0KPiBGaWxlICJDOlxob3N0ZWR0b29sY2FjaGVcd2luZG93c1xQeXRob25cMy4xMC4x MVx4NjRcbGliXA0KPiAgICAgICAgICAgc2l0ZS1wYWNrYWdlc1xvbm54cnVudGltZVxjYXBp XF9weWJpbmRfc3RhdGUucHkiLCBsaW5lIDMyLCBpbiA8bW9kdWxlPg0KPiBJbXBvcnRFcnJv cjogRExMIGxvYWQgZmFpbGVkIHdoaWxlIGltcG9ydGluZw0KPiBvbm54cnVudGltZV9weWJp bmQxMV9zdGF0ZTogVGhlIHNwZWNpZmllZCBtb2R1bGUgY291bGQgbm90IGJlIGZvdW5kLg0K PiANCj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+IA0KPiBU aGUgZm9sZGVyIGludm9sdmVkLCBpcyBhbiBvbm54IGNhcGkgKENhcGFiaWxpdHkpIGZvbGRl ci4gSSB1bnBhY2tlZA0KPiB0aGUgTVNJIHRvIG1ha2UgYSBmb2xkZXIgb24gdGhpcyBtYWNo aW5lIChub3QgbXkgVGVzdCBNYWNoaW5lKS4NCj4gDQo+IE5hbWU6IGdyYXhwZXJ0LXdpbmRv d3MtYW1kNjQtMy4xLjByYzEubXNpDQo+IFNpemU6IDE3NiwzOTQsMjQwIGJ5dGVzICgxNjgg TWlCKQ0KPiBTSEEyNTY6IEIzNEQ0QTVBQzlGQkVENTM0NzE4OTVEODA2RjI4RkEzOTlCRkJE MEE3MzE1MjkxRDVFRDc2MUNCOTUwMTBDRDgNCj4gDQo+IEs6XFRFTVBcbGliXG9ubnhydW50 aW1lXGNhcGk+ZGlyDQo+IA0KPiBUaHUsIDExLzIxLzIwMjQgIDExOjA0IFBNICAgIDxESVI+ ICAgICAgICAgIC4NCj4gVGh1LCAxMS8yMS8yMDI0ICAxMTowNCBQTSAgICA8RElSPiAgICAg ICAgICAuLg0KPiBTdW4sIDExLzEwLzIwMjQgIDAxOjM3IFBNICAgICAgICAxOCw1MjcsMjgw IERpcmVjdE1MLmRsbA0KPiBTdW4sIDExLzEwLzIwMjQgIDAxOjM3IFBNICAgICAgICAxOCwy NzYsODk2IG9ubnhydW50aW1lLmRsbA0KPiBTdW4sIDExLzEwLzIwMjQgIDAxOjM3IFBNICAg ICAgICAgICAgMjEsNTQ0IG9ubnhydW50aW1lX3Byb3ZpZGVyc19zaGFyZWQuZGxsDQo+IA0K PiBTdW4sIDExLzEwLzIwMjQgIDAxOjM4IFBNICAgICAgICAgICAgIDIsMjExIG9ubnhydW50 aW1lX2NvbGxlY3RfYnVpbGRfaW5mby5weWMNCj4gU3VuLCAxMS8xMC8yMDI0ICAwMTozOCBQ TSAgICAgICAgICAgIDU5LDIxNiBvbm54cnVudGltZV9pbmZlcmVuY2VfY29sbGVjdGlvbi5w eWMNCj4gU3VuLCAxMS8xMC8yMDI0ICAwMTozNyBQTSAgICAgICAgMjIsNDM4LDk0NCBvbm54 cnVudGltZV9weWJpbmQxMV9zdGF0ZS5weWQgICAgICAgIDw9PT0gTWF5IGFjdHVhbGx5IGJl IGEgRExMLCBoYXJkIHRvIHNheQ0KPiBTdW4sIDExLzEwLzIwMjQgIDAxOjM4IFBNICAgICAg ICAgICAgIDUsOTc3IG9ubnhydW50aW1lX3ZhbGlkYXRpb24ucHljDQo+IFN1biwgMTEvMTAv MjAyNCAgMDE6MzggUE0gICAgICAgICAgICAgICAyMzIgdmVyc2lvbl9pbmZvLnB5Yw0KPiBT dW4sIDExLzEwLzIwMjQgIDAxOjM4IFBNICAgICAgICAgICAgICAgMjAzIF9sZF9wcmVsb2Fk LnB5Yw0KPiBTdW4sIDExLzEwLzIwMjQgIDAxOjM4IFBNICAgICAgICAgICAgIDEsMzM2IF9w eWJpbmRfc3RhdGUucHljDQo+IFN1biwgMTEvMTAvMjAyNCAgMDE6MzggUE0gICAgICAgICAg ICAgICAyMDAgX19pbml0X18ucHljDQo+IA0KPiAkIGZpbGUgb25ueHJ1bnRpbWVfcHliaW5k MTFfc3RhdGUucHlkDQo+IG9ubnhydW50aW1lX3B5YmluZDExX3N0YXRlLnB5ZDogUEUzMisg ZXhlY3V0YWJsZSAoRExMKSAoY29uc29sZSkgeDg2LTY0LCBmb3IgTVMgV2luZG93cw0KPiAN Cj4gJCBmaWxlIG9ubnhydW50aW1lX2luZmVyZW5jZV9jb2xsZWN0aW9uLnB5Yw0KPiBvbm54 cnVudGltZV9pbmZlcmVuY2VfY29sbGVjdGlvbi5weWM6IGRhdGEgICAgPD09PSBzdHJhbmdl IGl0IGRvZXMgbm90IG1lbnRpb24gUEUzMi4NCj4gDQo+IG5vdGVwYWQgb25ueHJ1bnRpbWVf cHliaW5kMTFfc3RhdGUucHlkDQo+IA0KPiAgICAgIG9ubnhydW50aW1lX3B5YmluZDExX3N0 YXRlICAgICAgaW5pdGlhbGl6YXRpb24gZmFpbGVkICAgMS4yMC4wDQo+ICAgICAgT1JUIEJ1 aWxkIEluZm86IGdpdC1icmFuY2g9SEVBRCwgZ2l0LWNvbW1pdC1pZD1jNGZiNzI0ZTgxLCBi dWlsZCB0eXBlPVJlbGVhc2UsDQo+ICAgICAgY21ha2UgY3h4IGZsYWdzOiAvTVAgL2d1YXJk OmNmIC9EV0lOMzIgL0RfV0lORE9XUyAvRF9ESVNBQkxFX0NPTlNURVhQUl9NVVRFWF9DT05T VFJVQ1RPUg0KPiAgICAgICAgICAgICAgICAgICAgICAgL0RXSU5BUElfRkFNSUxZPTEwMCAv RFdJTlZFUj0weDBBMDAgL0RfV0lOMzJfV0lOTlQ9MHgwQTAwIC9ETlRERElfVkVSU0lPTj0w eDBBMDAwMDAwDQo+ICAgICAgICAgICAgICAgICAgICAgICAvUXNwZWN0cmUgL0RPTk5YUlVO VElNRV9FTkFCTEVfSU5URUxfTUVURU9SX0xBS0VfTU9CSUxFX1BMQVRGT1JNX1BFUkZfUEFU Q0ggL08yIC9PYjINCj4gICAgICAgICAgICAgICAgICAgICAgIC9ETkRFQlVHIC9aYzpfX2Nw bHVzcGx1cyAvRUhzYyAvd2QyNjgxMiAtREVJR0VOX0hBU19DOTlfTUFUSCAtRENQVUlORk9f U1VQUE9SVEVEDQo+IA0KPiAgICAgIFJldHVybiBsaXN0IG9mIGF2YWlsYWJsZSBFeGVjdXRp b24gUHJvdmlkZXJzIGluIHRoaXMgaW5zdGFsbGVkIHZlcnNpb24gb2YgT25ueHJ1bnRpbWUu IFRoZSBvcmRlciBvZg0KPiAgICAgIGVsZW1lbnRzIHJlcHJlc2VudHMgdGhlIGRlZmF1bHQg cHJpb3JpdHkgb3JkZXIgb2YgRXhlY3V0aW9uIFByb3ZpZGVycyBmcm9tIGhpZ2hlc3QgdG8g bG93ZXN0Lg0KPiANCj4gICAgICBnZXRfYXZhaWxhYmxlX3Byb3ZpZGVycw0KPiAgICAgIGdl dF92ZXJzaW9uX3N0cmluZw0KPiAgICAgIGdldF9idWlsZF9pbmZvDQo+ICAgICAgaGFzX2Nv bGxlY3RpdmVfb3BzDQo+IA0KPiBJdCBjb3VsZCBiZSwgdGhhdCBpdCBoYXMgc29tZSBlbGVt ZW50cyBvZiBQeXRob24gaW4gaXQsIGJ1dCBpdCBjb3VsZCBoYXZlDQo+IHJlZ3VsYXIgQysr IG9yIEMjIGxpYnJhcmllcyBmcm9tIE1pY3Jvc29mdCBib3VuZCBpbnRvIGl0LiBJIGp1c3Qg Y2FuJ3Qga2VlcA0KPiB1cCB3aXRoIHRoZXNlIGd1eXMgYW5kIHRoZWlyICJhbnl0aGluZyBn b2VzIiBtaXhpbmcgb2YgZXhlY3V0YWJsZXMgbm93IDotLw0KPiANCj4gb25ueHJ1bnRpbWVf cHJvdmlkZXJzX2N1ZGEuZGxsICAgICAgICA8PT09IE5WaWRpYQ0KPiBvbm54cnVudGltZV9w cm92aWRlcnNfY3VkYV91dC5kbGwNCj4gb25ueHJ1bnRpbWVfcHJvdmlkZXJzX2Nhbm4uZGxs DQo+IG9ubnhydW50aW1lX3Byb3ZpZGVyc19yb2NtLmRsbCAgICAgICAgPD09PSBBTUQNCj4g b25ueHJ1bnRpbWVfcHJvdmlkZXJzX2RubmwuZGxsDQo+IG9ubnhydW50aW1lX3Byb3ZpZGVy c192aXRpc2FpLmRsbA0KPiBvbm54cnVudGltZV9wcm92aWRlcnNfb3BlbnZpbm8uZGxsICAg IDw9PT0gSW50ZWwNCj4gb25ueHJ1bnRpbWVfcHJvdmlkZXJzX3RlbnNvcnJ0LmRsbA0KPiBv bm54cnVudGltZV9wcm92aWRlcnNfbWlncmFwaHguZGxsDQo+IA0KPiAqKioqKioqDQo+IA0K PiBPdXIgYnJlYWRjcnVtYiB0aGVuLCBpcw0KPiANCj4gICAgICBvbm54cnVudGltZV9weWJp bmQxMV9zdGF0ZS5weWQgICBETEwgbG9hZCBmYWlsZWQgd2hpbGUgaW1wb3J0aW5nDQo+IA0K PiBOb3QgdmVyeSBoZWxwZnVsIGVudHJ5LiBObyByZXNwb25zZS4gQSBzZWNvbmQgbGluayBs aWtlIHRoaXMgd2FzIHRoZQ0KPiBzYW1lIHdheSwgYW4gZW50cnksIG5vIHJlc3BvbnNlLg0K PiANCj4gICAgIGh0dHBzOi8vZ2l0aHViLmNvbS9taWNyb3NvZnQvb25ueHJ1bnRpbWUvaXNz dWVzLzE2MTE2DQo+IA0KPiBUaGV5IG1lbnRpb24gY2hlY2tpbmcgdGhlIC5weWQgd2l0aCBk dW1wYmluLiBCdXQgbGlrZWx5IHRoZSBkdW1wYmluDQo+IHdvdWxkIG5lZWQgdG8gYmUgaW4g dGhlIHBhdGggdG8gd29yayAoeW91IG1pZ2h0IG5lZWQgdGhlIHdob2xlIGZvbGRlcg0KPiB0 aGF0IGR1bXBiaW4uZXhlIGlzIGluLCBhcyBkdW1wYmluIG1pZ2h0IGJlIHVzaW5nIHNvbWUg RExMcykuDQo+IA0KPiAgICAgaHR0cHM6Ly9zdGFja292ZXJmbG93LmNvbS9xdWVzdGlvbnMv MjAyMDE4NjgvaW1wb3J0ZXJyb3ItZGxsLWxvYWQtZmFpbGVkLXRoZS1zcGVjaWZpZWQtbW9k dWxlLWNvdWxkLW5vdC1iZS1mb3VuZA0KPiANCj4gTm90ZSB0aGUgc2VyaWVzIG9mIGFwaV8g RExMIGZpbGVzIGF0IHRoZSB0b3AgbGV2ZWwgb2YgdGhlIGluc3RhbGwuDQo+IFNldHMgb2Yg dGhlc2UgYXJlIHVzZWQgcGVyIE9TIHZlcnNpb24uIEZpcmVmb3guZXhlIGZvciBleGFtcGxl LCBoYXMNCj4gYSAicHJvcGVyIHNldCIgYW5kIGRlbW9uc3RyYXRlcyB0byBkZXZlbG9wZXJz LCBub3cgeW91J3JlIHN1cHBvc2VkIHRvIGRvDQo+IGl0LiBJIGZyZXF1ZW50bHkgZmluZCBo YWxmLWJha2VkIHNldHMgb2YgdGhvc2Ugd3JhcHBlciBETExzIGluY2x1ZGVkDQo+IGluIGV4 ZWN1dGFibGVzLiBBdCBvbmUgdGltZSwgTWljcm9zb2Z0IHRyaWVkIHRvIGRpc3RyaWJ1dGUg dGhvc2UNCj4gYXQgdGhlIHN5c3RlbS13aWRlIGxldmVsLiBCdXQgdGhleSBtaWdodCBub3Qg YmUgZG9pbmcgdGhhdCB3aXRoIHRoZQ0KPiBzYW1lIGd1c3RvIGFzIGJlZm9yZS4gV2hhdCB0 aGUgYXBpXyBuYW1lIGFsbG93cywgaXMgbGlua2luZyB0byB0aGUgY29ycmVjdA0KPiBETEwg d2hlbiB0aGUgZXhlY3V0YWJsZSBpcyBhdCBydW50aW1lIHN0YXRlICh5b3UgZmlndXJlIG91 dCB5b3VyIGFjdHVhbA0KPiBETExzIGFzIHRoZSBwcm9ncmFtIGxvYWRzIGFuZCBydW5zKS4N Cj4gDQo+IEluIGEgQ29tbWFuZCBQcm9tcHQgYXMgYW4gb3JkaW5hcnkgdXNlcjoNCj4gDQo+ IEg6XFByb2dyYW0gRmlsZXNcTWljcm9zb2Z0IFZpc3VhbCBTdHVkaW9cMjAyMlxDb21tdW5p dHlcVkNcVG9vbHNcTVNWQ1wxNC4zMC4zMDcwNVxiaW5cSG9zdHg2NFx4NjQ+LlxkdW1wYmlu DQo+ICAgICAgIC9kZXBlbmRlbnRzIEQ6XFRFTVBcbGliXG9ubnhydW50aW1lXGNhcGlcb25u eHJ1bnRpbWVfcHliaW5kMTFfc3RhdGUucHlkDQo+IA0KPiAgICBJbWFnZSBoYXMgdGhlIGZv bGxvd2luZyBkZXBlbmRlbmNpZXM6DQo+IA0KPiAgICAgIHB5dGhvbjMxMS5kbGwNCj4gICAg ICBEaXJlY3RNTC5kbGwNCj4gICAgICBkM2QxMi5kbGwNCj4gICAgICBkeGdpLmRsbA0KPiAg ICAgIGR4Y29yZS5kbGwNCj4gICAgICBLRVJORUwzMi5kbGwNCj4gICAgICBBRFZBUEkzMi5k bGwNCj4gICAgICBhcGktbXMtd2luLWNvcmUtcGF0aC1sMS0xLTAuZGxsDQo+ICAgICAgTVNW Q1AxNDAuZGxsDQo+ICAgICAgTVNWQ1AxNDBfMS5kbGwNCj4gICAgICBWQ1JVTlRJTUUxNDAu ZGxsDQo+ICAgICAgVkNSVU5USU1FMTQwXzEuZGxsDQo+ICAgICAgYXBpLW1zLXdpbi1jcnQt cnVudGltZS1sMS0xLTAuZGxsDQo+ICAgICAgYXBpLW1zLXdpbi1jcnQtaGVhcC1sMS0xLTAu ZGxsDQo+ICAgICAgYXBpLW1zLXdpbi1jcnQtc3RyaW5nLWwxLTEtMC5kbGwNCj4gICAgICBh cGktbXMtd2luLWNydC1tYXRoLWwxLTEtMC5kbGwNCj4gICAgICBhcGktbXMtd2luLWNydC1z dGRpby1sMS0xLTAuZGxsDQo+ICAgICAgYXBpLW1zLXdpbi1jcnQtZmlsZXN5c3RlbS1sMS0x LTAuZGxsDQo+ICAgICAgYXBpLW1zLXdpbi1jcnQtY29udmVydC1sMS0xLTAuZGxsDQo+ICAg ICAgYXBpLW1zLXdpbi1jcnQtdGltZS1sMS0xLTAuZGxsDQo+ICAgICAgYXBpLW1zLXdpbi1j cnQtbG9jYWxlLWwxLTEtMC5kbGwNCj4gDQo+IENoZWNraW5nIHRoZSBtYWluIEdyYVhwZXJ0 IGZvbGRlciwgaXQgaGFzIHRob3NlIGFwaS0qIG1hcHBpbmcgRExMIGVudHJpZXMuDQo+IE1h cHBpbmcgRExMcyBoYXZlIGEgc21hbGwgc2l6ZSBhbmQgYSBtaW5pbWFsIHN0cnVjdHVyZS4g VGhleSBzaG91bGQgbm90DQo+IGJlIGxhcmdlIGZpbGVzLiBOb3RpY2UgdGhhdCBWQyBSdW50 aW1lIGxpYnJhcmllcyBhcmUgaW4gdGhlIGZvbGRlciB0b28uDQo+IFRvIGJ1dHRyZXNzIHRo b3NlLCB5b3UgY2FuIGdldCBhIG11bHRpLXZlcnNpb24gVkMgcGFja2FnZS4gTGlrZSwNCj4g SSBkb24ndCBsaWtlIHRoZSBsb29rIG9mIHRoZSAiVkNSVU5USU1FMTQwXzEuZGxsIiBlbnRy eSwgdGhhdCBsb29rcw0KPiByZWNrbGVzcy4NCj4gDQo+IEluc3RhbGwgdGhlIHg4NiBhbmQg eDY3NCBmcm9tIGhlcmUsIHRvIGZpbGwgeW91ciBzeXN0ZW0gZm9sZGVyIHdpdGgNCj4gDQo+ IGh0dHBzOi8vbGVhcm4ubWljcm9zb2Z0LmNvbS9lbi11cy9jcHAvd2luZG93cy9sYXRlc3Qt c3VwcG9ydGVkLXZjLXJlZGlzdD92aWV3PW1zdmMtMTcwDQo+IA0KPiAgICAgIlZpc3VhbCBT dHVkaW8gMjAxNSwgMjAxNywgMjAxOSwgYW5kIDIwMjIgcnVudGltZXMiDQo+IA0KPiBUaGUg VkNSVU5USU1FMTQwXzEuZGxsIG1pZ2h0IHdlbGwgYmUgYSBWaXN1YWwgU3R1ZGlvIDIwMTUg aXRlbS4NCj4gDQo+IEl0J3MgbXkgdW5pbmZvcm1lZCBvcGluaW9uIHJpZ2h0IG5vdywgdGhh dCB0aGlzIGNvZGUgaGFzIHBsZW50eQ0KPiBvZiBkZWZlbnNpdmUgY29kaW5nLCBhbmQgaXQg c2hvdWxkIGJlIGFibGUgdG8gdGVsbCB0aGF0IHlvdXIgb2xkDQo+IEFNRCBjYXJkIGRvZXMg bm90IG1hdGNoIGFueSBvZiB0aGUgRGlyZWN0TUwgKE1hY2hpbmUgTGVhcm5pbmcpIHR5cGUN Cj4gaGFyZHdhcmVzLCBzdWNoIGFzIFJPQ00uIFRvIGdldCBkZWNlbnQgaGFyZHdhcmUsIGlz IGdvaW5nDQo+IHRvIGJlICQ1MDAgcGx1cy4gVG8gZ2V0IGEgcmVjZW50IENVREEgb3IgYSBS T0NNIHRoYXQgaXMgdXAgdG8gZGF0ZQ0KPiBhbmQgcmVhZHkgZm9yIGFueXRoaW5nLiBJdCdz IG5vdCBqdXN0IGFueSBvbGQgQ1VEQSBlaXRoZXIsIGEgYml0DQo+IGRpc2luZ2VudW91cyBp ZiB5b3UgYXNrIG1lLiBJIGNhbid0IHNlZSBob3cgdGhleSBjYW5ub3QgYW5nbGUNCj4gZm9y IGF0IGxlYXN0IGEgUlRYNDA2MCBmb3IgdGhpcywgYXQgTlZpZGlhIGhlYWRxdWFydGVycyA6 LSkNCj4gT3duaW5nIGFtIFJUWDQwOTAgd291bGQgb25seSBnbyBmYXN0ZXIuDQo+IA0KPiBU aGlzIGNvZGUgc2hvdWxkIGFsc28gYmUgYWJsZSB0byBydW4gb24gYSBDUFUsIGJ1dCB0aGVu IHdlIGRvbid0DQo+IGtub3cgaWYgdGhlIENQVSBoYXMgdG8gaGF2ZSBQb3B1bGF0aW9uIENv dW50IGluc3RydWN0aW9uIChQT1BDTlQpDQo+IG9yIFNTRSA0LjIgZm9yIGV4YW1wbGUuIExp ZmUgaXMgZmlsbGVkIHdpdGggdW5jZXJ0YWludHkuDQo+IA0KPiAgICAgUGF1bA0KDQpUaGFu a3MgZm9yIHRoZSBpbmZvLiAgSSdtIG5vdCBhbHdheXMgc3VyZSBvZiB3aGF0IHlvdSBhcmUg c2F5aW5nIGFzIHlvdSANCmFyZSBhIGxvdCBtb3JlIGNvbXB1dGVyIHNhYXZ5IHRoYW4gSSBh bSwgbG9sLiBZb3UgZGlkIG1lbnRpb24gb25lIHRoaW5nIA0KYWJvdmUgdGhvdWdoIHRoYXQg Y2F1Z2h0IG15IGV5ZSBhbmQgaGFkIHRvIGRvIHdpdGggVmlzdWFsIFN0dWRpby4gIEFmdGVy IA0KbXkgb3duIHJlc2VhcmNoIG9mIHRoZSBlcnJvciBhIHdlZWsgYWdvLCBJIGNhbWUgYWNy b3NzIHRoZSBzYW1lIA0KaW5mb3JtYXRpb24gY29uY2VybmluZyBpbnN0YWxsYXRpb24gb2Yg VmlzdWFsIFN0dWRpbyBhbmQgaGFkIGFscmVhZHkgDQppbnN0YWxsZWQgdGhlIGZpbGVzIHlv dSBsaW5rZWQgdG8gYWJvdmUuICBBcyBJIGNoZWNrZWQgbXkgaW5zdGFsbGVkIA0KdmVyc2lv bnMsIEkgaGFkIHZlcnNpb25zIGdvaW5nIGJhY2sgdG8gMjAxMyBvbiBteSBXaW4gUEMuICBT aW5jZSBJIHNhdyANCnZlcnNpb25zIGdvaW5nIGJhY2sgdG8gMjAwNSB0aGVyZSwgSSB3ZW50 IGFoZWFkIGFuZCBpbnN0YWxsZWQgYmFjayB0byANCicwNS4gIFVwb24gdHJ5aW5nIHRvIHN0 YXJ0IEdyYVhwZXJ0LCBzYW1lIGVycm9yIGJveCwgaG93ZXZlciwgYW5kIA0KcHJvZ3JhbSBz dGlsbCB3b24ndCBvcGVuLg0KDQpJJ20gcHJldHR5IG11Y2ggZ29pbmcgdG8gZ2l2ZSB1cCBv biB0aGlzIG9uZSBJIHRoaW5rIHVudGlsIHRoZSANCmRldmVsb3BlcnMgbWF5YmUgYWRkcmVz cyB0aGUgaXNzdWUgKHVubGVzcyB5b3UgaGF2ZSBhbnkgbW9yZSANCnN1Z2dlc3Rpb25zKSwg d2hpY2ggdGhleSBhcmUgYXdhcmUgb2YuICBBcyBJIG1lbnRpb25lZCBwcmlvciwgdGhlIA0K cHJvZ3JhbSBkb2VzIHNlZW0gdG8gcnVuIGluIFVidW50dSB3aXRob3V0IGlzc3VlcyBhbmQs IGV2ZW4gdGhvdWdoIEkgDQpoYXZlIHRvIHJlYm9vdCBpbnRvIFdpbiBvbmNlIHByb2Nlc3Np bmcgaXMgZG9uZSBpbiBVYnVudHUsIEkgY2FuIGxpdmUgDQp3aXRoIGl0IGZvciBub3cuICBJ IGRvbid0IGRvIHRoYXQgbXVjaCBvbiB0aGUgaW1hZ2UgcHJvY2Vzc2luZyBzaWRlIG9mIA0K YXN0cm9ub215IGFueWhvdyBoYXZpbmcgc29sZCBvZmYgbW9zdCBvZiBteSB0ZWxlc2NvcGVz IGEgbG9uZyB0aW1lIGFnbywgDQpidXQgaGF2ZSBiZWVuIGN1cmlvdXMgYWJvdXQgdGhlIGxh dGVzdCBpbWFnZSBwcm9jZXNzaW5nIHRvb2xzIGF2YWlsYWJsZSANCnRoZXNlIGRheXMgYW5k IHRob3VnaHQgSSB3b3VsZCB0cnkgdGhlbSBvdXQgb24gc29tZSBhbHJlYWR5IHNhdmVkIGJ1 dCANCnVucHJvY2Vzc2VkIGltYWdlcyBmcm9tIHRoZSBwYXN0Lg0KDQpJIHdpbGwgc2F5IHRo YXQgaW4gdGhlIHJlbGVhc2VzIHNlY3Rpb24gb2YgR3JhWHBlcnQgYXQgR2l0aHViLCBvbiBh IA0Kd2hpbSwgSSBmb3VuZCB0aGF0IGFuIGVhcmxpZXIgdmVyc2lvbiAoMi4yLjIpIGRvZXMg d29yayBvbiBteSBXaW4gUEMuIA0KSSdtIHdpbGxpbmcgdG8gYmV0IHRoYXQgMy4wLjAuZGV2 MCB3b3VsZCBhbHNvIHdvcmsgYXMgdGhhdCB3YXMgdGhlIGxhc3QgDQp2ZXJzaW9uIGJlZm9y ZSB0aGV5IGJlZ2FuIHVzaW5nIC5vbm54IGZvcm1hdCBmb3IgdGhlaXIgbW9kZWxzLg0KDQog IGh0dHBzOi8vZ2l0aHViLmNvbS9TdGVmZmVuaGlyL0dyYVhwZXJ0L3JlbGVhc2VzP3BhZ2U9 MQ0KDQpUaGFua3MgYWdhaW4gZm9yIHlvdXIgaGVscC4gVGhpcyBoYXNuJ3QgYmVlbiB0aGUg b25seSBwcm9ncmFtIG5lZWRpbmcgDQp0d2Vha2luZyB0byBnZXQgd29ya2luZyBvbiBteSBQ Qy4gIEkgdHJpZWQgYSBjb3VwbGUgb2Ygb3RoZXJzIG92ZXIgdGhlIA0KbGFzdCBtb250aCBm b3IgYXN0cm9ub215IHRvby4gIFRoYW5rZnVsbHksIG90aGVyIHVzZXJzIHdpdGggc2xvdy8g DQppbmFkZXF1YXRlIFBDcyB3ZXJlIGFibGUgdG8gZGV2ZWxvcCBhbHRlcm5hdGUgcHJvZ3Jh bSBmaWxlcyB0byBhbGxvdyB0aGUgDQptYXN0ZXIgcHJvZ3JhbXMgdG8gd29yay4gIFRoZSBi aWcgaXNzdWUgd2l0aCB0aG9zZSBwcm9ncmFtcyB3YXMgdGhhdCANCnRoZXkgbm9ybWFsbHkg d291bGRuJ3QgZnVuY3Rpb24gb24gTk9OLUFWWCBQQ3MgKGFuZCBtaW5lIG9mIGNvdXJzZSBp cyANCm5vbi1BVlgpLCBidXQgdGhleSBtb2RpZmllZCB0aGUgcHJvZ3JhbXMgdG8gYWxsb3cg aXQuDQo=

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to Jackson Durmott on Fri Nov 22 21:56:27 2024
    On Fri, 11/22/2024 3:56 PM, Jackson Durmott wrote:
    On 11/22/24 1:05 AM, Paul wrote:
    On Thu, 11/21/2024 7:24 PM, Jackson Durmott wrote:
    On 11/21/24 5:11 PM, Paul wrote:
    On Thu, 11/21/2024 9:25 AM, Jackson Durmott wrote:
    On 11/21/24 7:13 AM, Paul wrote:



    How many astronomy software tools do you have ?

    First of all, see if you have a C:\hostedtoolcache

    Temporarily rename that, and run GraXPert again.

    I have quite a few astronomy tools, but most are on a separate hard drive and are portable, not requiring installation.  GraXpert was an exception, however, although it is self contained on Ubuntu.

    Well, I just searched and don't see that file/ folder on the C drive. >>>>>>

    OK, in my picture, you can see GraXPert is "sniffing" a
    particular directory that I do not have.

    And in your picture, you can see the software claiming
    it is *starting* materials in C:\hosted...  so it has
    located such a thing.

    C:
    cd \
    dir          # Check for visible files
    dir /AH      # Check for hidden files

         Paul

    https://ibb.co/30FY4TV

    The file or folder it claims it is finding is not there.

    OK, the code lies about the path the module comes from.
    Some of these paths, are the hardwired paths on the developer machine.
    Only the name of the routine on the end makes sense.

    ****** Your error message trace (via Snippingtool OCR) *******

    cx_Freeze: Python error in main script

    Traceback (most recent call last):
    File "C:\hostedtoolcache\windows\Python\3.10.11\x64\Lib\
              site-packages\cx_Freeze\initscripts\ __ startup __. py", line 138, in run
    File "C:\hostedtoolcache\windows\Python\3.10.11\x64\Lib\
              site-packages\cx_Freeze\initscripts\console.py", line 17, in run
    File "graxpert\main.py", line 18, in <module>
    File "D:\a\GraXpert\GraXpert\graxpert\ai_model_handling.py', line 7, in <module>
    File "C:\hostedtoolcache\windows\Python\3.10.11\x64\lib\
              site-packages\onnxruntime\ __ init _. py", line 57, in <module>
    File "C:\hostedtoolcache\windows\Python\3.10.11\x64\lib\
              site-packages\onnxruntime\ __ init _. py", line 23, in <module>
    File "C:\hostedtoolcache\windows\Python\3.10.11\x64\lib\
              site-packages\onnxruntime\capi\_pybind_state.py", line 32, in <module>
    ImportError: DLL load failed while importing
    onnxruntime_pybind11_state: The specified module could not be found.

    ***************************************

    The folder involved, is an onnx capi (Capability) folder. I unpacked
    the MSI to make a folder on this machine (not my Test Machine).

    Name: graxpert-windows-amd64-3.1.0rc1.msi
    Size: 176,394,240 bytes (168 MiB)
    SHA256: B34D4A5AC9FBED53471895D806F28FA399BFBD0A7315291D5ED761CB95010CD8

    K:\TEMP\lib\onnxruntime\capi>dir

    Thu, 11/21/2024  11:04 PM    <DIR>          .
    Thu, 11/21/2024  11:04 PM    <DIR>          ..
    Sun, 11/10/2024  01:37 PM        18,527,280 DirectML.dll
    Sun, 11/10/2024  01:37 PM        18,276,896 onnxruntime.dll
    Sun, 11/10/2024  01:37 PM            21,544 onnxruntime_providers_shared.dll

    Sun, 11/10/2024  01:38 PM             2,211 onnxruntime_collect_build_info.pyc
    Sun, 11/10/2024  01:38 PM            59,216 onnxruntime_inference_collection.pyc
    Sun, 11/10/2024  01:37 PM        22,438,944 onnxruntime_pybind11_state.pyd        <=== May actually be a DLL, hard to say
    Sun, 11/10/2024  01:38 PM             5,977 onnxruntime_validation.pyc
    Sun, 11/10/2024  01:38 PM               232 version_info.pyc >> Sun, 11/10/2024  01:38 PM               203 _ld_preload.pyc >> Sun, 11/10/2024  01:38 PM             1,336 _pybind_state.pyc >> Sun, 11/10/2024  01:38 PM               200 __init__.pyc

    $ file onnxruntime_pybind11_state.pyd
    onnxruntime_pybind11_state.pyd: PE32+ executable (DLL) (console) x86-64, for MS Windows

    $ file onnxruntime_inference_collection.pyc
    onnxruntime_inference_collection.pyc: data    <=== strange it does not mention PE32.

    notepad onnxruntime_pybind11_state.pyd

         onnxruntime_pybind11_state      initialization failed   1.20.0
         ORT Build Info: git-branch=HEAD, git-commit-id=c4fb724e81, build type=Release,
         cmake cxx flags: /MP /guard:cf /DWIN32 /D_WINDOWS /D_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR
                          /DWINAPI_FAMILY=100 /DWINVER=0x0A00 /D_WIN32_WINNT=0x0A00 /DNTDDI_VERSION=0x0A000000
                          /Qspectre /DONNXRUNTIME_ENABLE_INTEL_METEOR_LAKE_MOBILE_PLATFORM_PERF_PATCH /O2 /Ob2
                          /DNDEBUG /Zc:__cplusplus /EHsc /wd26812 -DEIGEN_HAS_C99_MATH -DCPUINFO_SUPPORTED

         Return list of available Execution Providers in this installed version of Onnxruntime. The order of
         elements represents the default priority order of Execution Providers from highest to lowest.

         get_available_providers
         get_version_string
         get_build_info
         has_collective_ops

    It could be, that it has some elements of Python in it, but it could have
    regular C++ or C# libraries from Microsoft bound into it. I just can't keep >> up with these guys and their "anything goes" mixing of executables now :-/ >>
    onnxruntime_providers_cuda.dll        <=== NVidia
    onnxruntime_providers_cuda_ut.dll
    onnxruntime_providers_cann.dll
    onnxruntime_providers_rocm.dll        <=== AMD
    onnxruntime_providers_dnnl.dll
    onnxruntime_providers_vitisai.dll
    onnxruntime_providers_openvino.dll    <=== Intel
    onnxruntime_providers_tensorrt.dll
    onnxruntime_providers_migraphx.dll

    *******

    Our breadcrumb then, is

         onnxruntime_pybind11_state.pyd   DLL load failed while importing >>
    Not very helpful entry. No response. A second link like this was the
    same way, an entry, no response.

        https://github.com/microsoft/onnxruntime/issues/16116

    They mention checking the .pyd with dumpbin. But likely the dumpbin
    would need to be in the path to work (you might need the whole folder
    that dumpbin.exe is in, as dumpbin might be using some DLLs).

        https://stackoverflow.com/questions/20201868/importerror-dll-load-failed-the-specified-module-could-not-be-found

    Note the series of api_ DLL files at the top level of the install.
    Sets of these are used per OS version. Firefox.exe for example, has
    a "proper set" and demonstrates to developers, now you're supposed to do
    it. I frequently find half-baked sets of those wrapper DLLs included
    in executables. At one time, Microsoft tried to distribute those
    at the system-wide level. But they might not be doing that with the
    same gusto as before. What the api_ name allows, is linking to the correct >> DLL when the executable is at runtime state (you figure out your actual
    DLLs as the program loads and runs).

    In a Command Prompt as an ordinary user:

    H:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.30.30705\bin\Hostx64\x64>.\dumpbin
          /dependents D:\TEMP\lib\onnxruntime\capi\onnxruntime_pybind11_state.pyd

       Image has the following dependencies:

         python311.dll
         DirectML.dll
         d3d12.dll
         dxgi.dll
         dxcore.dll
         KERNEL32.dll
         ADVAPI32.dll
         api-ms-win-core-path-l1-1-0.dll
         MSVCP140.dll
         MSVCP140_1.dll
         VCRUNTIME140.dll
         VCRUNTIME140_1.dll
         api-ms-win-crt-runtime-l1-1-0.dll
         api-ms-win-crt-heap-l1-1-0.dll
         api-ms-win-crt-string-l1-1-0.dll
         api-ms-win-crt-math-l1-1-0.dll
         api-ms-win-crt-stdio-l1-1-0.dll
         api-ms-win-crt-filesystem-l1-1-0.dll
         api-ms-win-crt-convert-l1-1-0.dll
         api-ms-win-crt-time-l1-1-0.dll
         api-ms-win-crt-locale-l1-1-0.dll

    Checking the main GraXpert folder, it has those api-* mapping DLL entries. >> Mapping DLLs have a small size and a minimal structure. They should not
    be large files. Notice that VC Runtime libraries are in the folder too.
    To buttress those, you can get a multi-version VC package. Like,
    I don't like the look of the "VCRUNTIME140_1.dll" entry, that looks
    reckless.

    Install the x86 and x674 from here, to fill your system folder with

    https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170

        "Visual Studio 2015, 2017, 2019, and 2022 runtimes"

    The VCRUNTIME140_1.dll might well be a Visual Studio 2015 item.

    It's my uninformed opinion right now, that this code has plenty
    of defensive coding, and it should be able to tell that your old
    AMD card does not match any of the DirectML (Machine Learning) type
    hardwares, such as ROCM. To get decent hardware, is going
    to be $500 plus. To get a recent CUDA or a ROCM that is up to date
    and ready for anything. It's not just any old CUDA either, a bit
    disingenuous if you ask me. I can't see how they cannot angle
    for at least a RTX4060 for this, at NVidia headquarters :-)
    Owning am RTX4090 would only go faster.

    This code should also be able to run on a CPU, but then we don't
    know if the CPU has to have Population Count instruction (POPCNT)
    or SSE 4.2 for example. Life is filled with uncertainty.

        Paul

    Thanks for the info.  I'm not always sure of what you are saying as you are a lot more computer saavy than I am, lol. You did mention one thing above though that caught my eye and had to do with Visual Studio.  After my own research of the error a
    week ago, I came across the same information concerning installation of Visual Studio and had already installed the files you linked to above.  As I checked my installed versions, I had versions going back to 2013 on my Win PC.  Since I saw versions
    going back to 2005 there, I went ahead and installed back to '05.  Upon trying to start GraXpert, same error box, however, and program still won't open.

    I'm pretty much going to give up on this one I think until the developers maybe address the issue (unless you have any more suggestions), which they are aware of.  As I mentioned prior, the program does seem to run in Ubuntu without issues and, even
    though I have to reboot into Win once processing is done in Ubuntu, I can live with it for now.  I don't do that much on the image processing side of astronomy anyhow having sold off most of my telescopes a long time ago, but have been curious about the
    latest image processing tools available these days and thought I would try them out on some already saved but unprocessed images from the past.

    I will say that in the releases section of GraXpert at Github, on a whim, I found that an earlier version (2.2.2) does work on my Win PC. I'm willing to bet that 3.0.0.dev0 would also work as that was the last version before they began using .onnx
    format for their models.

     https://github.com/Steffenhir/GraXpert/releases?page=1

    Thanks again for your help. This hasn't been the only program needing tweaking to get working on my PC.  I tried a couple of others over the last month for astronomy too.  Thankfully, other users with slow/ inadequate PCs were able to develop
    alternate program files to allow the master programs to work.  The big issue with those programs was that they normally wouldn't function on NON-AVX PCs (and mine of course is non-AVX), but they modified the programs to allow it.

    My job is to provide breadcrumbs. Normally I expect the people in front
    of the situation, to have the best information about what is going on.
    Many times, I can't reproduce these things exactly, and details matter.
    My hardware isn't always the newest, and some hardware choices, I wouldn't
    be buying any, since they seem to have no merit. Just about every project
    I've tried to test, that relied on GPU acceleration, did not work.

    I see you could file two bug reports.

    1) A bug report for the "DLL won't load" case.

    2) A request to the developer, to
    - Put the preference file in its place right away.
    The file is not rocket science, it's a short text file after all. 1KB sized.
    - set the defaults to "Safe" values. Disable hardware acceleration.
    In the user manual, tell the users to switch on the hardware acceleration.

    The GraXpert.log file on my machine, only has one message. it says the preferences.json is missing and that the program will write it out at the
    end of the session. And that's the evidence captured in Process Monitor.
    You can see it writing the file.

    It needs to write the file to the empty directory before this.
    Like, how about putting "Preference.json" in the .msi, with the
    very last entry which is hardware acceleration, turned off.
    Then the file is populated, and the user can "debug" to their
    hearts content. If the user switches on Hardware Acceleration
    and something crashes, the user knows the Preferences can be
    restored to a "safe" state later.

    Even with Hardware Acceleration turned off, ONNX is *still* going to
    run, *Still* evaluate ML (Machine Learning) providers, and blow a fuse. Best Guess.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to Jackson Durmott on Sat Nov 23 05:16:34 2024
    On Fri, 11/22/2024 3:56 PM, Jackson Durmott wrote:
    On 11/22/24 1:05 AM, Paul wrote:
    On Thu, 11/21/2024 7:24 PM, Jackson Durmott wrote:
    On 11/21/24 5:11 PM, Paul wrote:
    On Thu, 11/21/2024 9:25 AM, Jackson Durmott wrote:
    On 11/21/24 7:13 AM, Paul wrote:



    How many astronomy software tools do you have ?

    First of all, see if you have a C:\hostedtoolcache

    Temporarily rename that, and run GraXPert again.

    I have quite a few astronomy tools, but most are on a separate hard drive and are portable, not requiring installation.  GraXpert was an exception, however, although it is self contained on Ubuntu.

    Well, I just searched and don't see that file/ folder on the C drive. >>>>>>

    OK, in my picture, you can see GraXPert is "sniffing" a
    particular directory that I do not have.

    And in your picture, you can see the software claiming
    it is *starting* materials in C:\hosted...  so it has
    located such a thing.

    C:
    cd \
    dir          # Check for visible files
    dir /AH      # Check for hidden files

         Paul

    https://ibb.co/30FY4TV

    The file or folder it claims it is finding is not there.

    OK, the code lies about the path the module comes from.
    Some of these paths, are the hardwired paths on the developer machine.
    Only the name of the routine on the end makes sense.

    ****** Your error message trace (via Snippingtool OCR) *******

    cx_Freeze: Python error in main script

    Traceback (most recent call last):
    File "C:\hostedtoolcache\windows\Python\3.10.11\x64\Lib\
              site-packages\cx_Freeze\initscripts\ __ startup __. py", line 138, in run
    File "C:\hostedtoolcache\windows\Python\3.10.11\x64\Lib\
              site-packages\cx_Freeze\initscripts\console.py", line 17, in run
    File "graxpert\main.py", line 18, in <module>
    File "D:\a\GraXpert\GraXpert\graxpert\ai_model_handling.py', line 7, in <module>
    File "C:\hostedtoolcache\windows\Python\3.10.11\x64\lib\
              site-packages\onnxruntime\ __ init _. py", line 57, in <module>
    File "C:\hostedtoolcache\windows\Python\3.10.11\x64\lib\
              site-packages\onnxruntime\ __ init _. py", line 23, in <module>
    File "C:\hostedtoolcache\windows\Python\3.10.11\x64\lib\
              site-packages\onnxruntime\capi\_pybind_state.py", line 32, in <module>
    ImportError: DLL load failed while importing
    onnxruntime_pybind11_state: The specified module could not be found.

    ***************************************

    The folder involved, is an onnx capi (Capability) folder. I unpacked
    the MSI to make a folder on this machine (not my Test Machine).

    Name: graxpert-windows-amd64-3.1.0rc1.msi
    Size: 176,394,240 bytes (168 MiB)
    SHA256: B34D4A5AC9FBED53471895D806F28FA399BFBD0A7315291D5ED761CB95010CD8

    K:\TEMP\lib\onnxruntime\capi>dir

    Thu, 11/21/2024  11:04 PM    <DIR>          .
    Thu, 11/21/2024  11:04 PM    <DIR>          ..
    Sun, 11/10/2024  01:37 PM        18,527,280 DirectML.dll
    Sun, 11/10/2024  01:37 PM        18,276,896 onnxruntime.dll
    Sun, 11/10/2024  01:37 PM            21,544 onnxruntime_providers_shared.dll

    Sun, 11/10/2024  01:38 PM             2,211 onnxruntime_collect_build_info.pyc
    Sun, 11/10/2024  01:38 PM            59,216 onnxruntime_inference_collection.pyc
    Sun, 11/10/2024  01:37 PM        22,438,944 onnxruntime_pybind11_state.pyd        <=== May actually be a DLL, hard to say
    Sun, 11/10/2024  01:38 PM             5,977 onnxruntime_validation.pyc
    Sun, 11/10/2024  01:38 PM               232 version_info.pyc >> Sun, 11/10/2024  01:38 PM               203 _ld_preload.pyc >> Sun, 11/10/2024  01:38 PM             1,336 _pybind_state.pyc >> Sun, 11/10/2024  01:38 PM               200 __init__.pyc

    $ file onnxruntime_pybind11_state.pyd
    onnxruntime_pybind11_state.pyd: PE32+ executable (DLL) (console) x86-64, for MS Windows

    $ file onnxruntime_inference_collection.pyc
    onnxruntime_inference_collection.pyc: data    <=== strange it does not mention PE32.

    notepad onnxruntime_pybind11_state.pyd

         onnxruntime_pybind11_state      initialization failed   1.20.0
         ORT Build Info: git-branch=HEAD, git-commit-id=c4fb724e81, build type=Release,
         cmake cxx flags: /MP /guard:cf /DWIN32 /D_WINDOWS /D_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR
                          /DWINAPI_FAMILY=100 /DWINVER=0x0A00 /D_WIN32_WINNT=0x0A00 /DNTDDI_VERSION=0x0A000000
                          /Qspectre /DONNXRUNTIME_ENABLE_INTEL_METEOR_LAKE_MOBILE_PLATFORM_PERF_PATCH /O2 /Ob2
                          /DNDEBUG /Zc:__cplusplus /EHsc /wd26812 -DEIGEN_HAS_C99_MATH -DCPUINFO_SUPPORTED

         Return list of available Execution Providers in this installed version of Onnxruntime. The order of
         elements represents the default priority order of Execution Providers from highest to lowest.

         get_available_providers
         get_version_string
         get_build_info
         has_collective_ops

    It could be, that it has some elements of Python in it, but it could have
    regular C++ or C# libraries from Microsoft bound into it. I just can't keep >> up with these guys and their "anything goes" mixing of executables now :-/ >>
    onnxruntime_providers_cuda.dll        <=== NVidia
    onnxruntime_providers_cuda_ut.dll
    onnxruntime_providers_cann.dll
    onnxruntime_providers_rocm.dll        <=== AMD
    onnxruntime_providers_dnnl.dll
    onnxruntime_providers_vitisai.dll
    onnxruntime_providers_openvino.dll    <=== Intel
    onnxruntime_providers_tensorrt.dll
    onnxruntime_providers_migraphx.dll

    *******

    Our breadcrumb then, is

         onnxruntime_pybind11_state.pyd   DLL load failed while importing >>
    Not very helpful entry. No response. A second link like this was the
    same way, an entry, no response.

        https://github.com/microsoft/onnxruntime/issues/16116

    They mention checking the .pyd with dumpbin. But likely the dumpbin
    would need to be in the path to work (you might need the whole folder
    that dumpbin.exe is in, as dumpbin might be using some DLLs).

        https://stackoverflow.com/questions/20201868/importerror-dll-load-failed-the-specified-module-could-not-be-found

    Note the series of api_ DLL files at the top level of the install.
    Sets of these are used per OS version. Firefox.exe for example, has
    a "proper set" and demonstrates to developers, now you're supposed to do
    it. I frequently find half-baked sets of those wrapper DLLs included
    in executables. At one time, Microsoft tried to distribute those
    at the system-wide level. But they might not be doing that with the
    same gusto as before. What the api_ name allows, is linking to the correct >> DLL when the executable is at runtime state (you figure out your actual
    DLLs as the program loads and runs).

    In a Command Prompt as an ordinary user:

    H:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.30.30705\bin\Hostx64\x64>.\dumpbin
          /dependents D:\TEMP\lib\onnxruntime\capi\onnxruntime_pybind11_state.pyd

       Image has the following dependencies:

         python311.dll
         DirectML.dll
         d3d12.dll
         dxgi.dll
         dxcore.dll
         KERNEL32.dll
         ADVAPI32.dll
         api-ms-win-core-path-l1-1-0.dll
         MSVCP140.dll
         MSVCP140_1.dll
         VCRUNTIME140.dll
         VCRUNTIME140_1.dll
         api-ms-win-crt-runtime-l1-1-0.dll
         api-ms-win-crt-heap-l1-1-0.dll
         api-ms-win-crt-string-l1-1-0.dll
         api-ms-win-crt-math-l1-1-0.dll
         api-ms-win-crt-stdio-l1-1-0.dll
         api-ms-win-crt-filesystem-l1-1-0.dll
         api-ms-win-crt-convert-l1-1-0.dll
         api-ms-win-crt-time-l1-1-0.dll
         api-ms-win-crt-locale-l1-1-0.dll

    Checking the main GraXpert folder, it has those api-* mapping DLL entries. >> Mapping DLLs have a small size and a minimal structure. They should not
    be large files. Notice that VC Runtime libraries are in the folder too.
    To buttress those, you can get a multi-version VC package. Like,
    I don't like the look of the "VCRUNTIME140_1.dll" entry, that looks
    reckless.

    Install the x86 and x674 from here, to fill your system folder with

    https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170

        "Visual Studio 2015, 2017, 2019, and 2022 runtimes"

    The VCRUNTIME140_1.dll might well be a Visual Studio 2015 item.

    It's my uninformed opinion right now, that this code has plenty
    of defensive coding, and it should be able to tell that your old
    AMD card does not match any of the DirectML (Machine Learning) type
    hardwares, such as ROCM. To get decent hardware, is going
    to be $500 plus. To get a recent CUDA or a ROCM that is up to date
    and ready for anything. It's not just any old CUDA either, a bit
    disingenuous if you ask me. I can't see how they cannot angle
    for at least a RTX4060 for this, at NVidia headquarters :-)
    Owning am RTX4090 would only go faster.

    This code should also be able to run on a CPU, but then we don't
    know if the CPU has to have Population Count instruction (POPCNT)
    or SSE 4.2 for example. Life is filled with uncertainty.

        Paul

    Thanks for the info.  I'm not always sure of what you are saying as you are a lot more computer saavy than I am, lol. You did mention one thing above though that caught my eye and had to do with Visual Studio.  After my own research of the error a
    week ago, I came across the same information concerning installation of Visual Studio and had already installed the files you linked to above.  As I checked my installed versions, I had versions going back to 2013 on my Win PC.  Since I saw versions
    going back to 2005 there, I went ahead and installed back to '05.  Upon trying to start GraXpert, same error box, however, and program still won't open.

    I'm pretty much going to give up on this one I think until the developers maybe address the issue (unless you have any more suggestions), which they are aware of.  As I mentioned prior, the program does seem to run in Ubuntu without issues and, even
    though I have to reboot into Win once processing is done in Ubuntu, I can live with it for now.  I don't do that much on the image processing side of astronomy anyhow having sold off most of my telescopes a long time ago, but have been curious about the
    latest image processing tools available these days and thought I would try them out on some already saved but unprocessed images from the past.

    I will say that in the releases section of GraXpert at Github, on a whim, I found that an earlier version (2.2.2) does work on my Win PC. I'm willing to bet that 3.0.0.dev0 would also work as that was the last version before they began using .onnx
    format for their models.

     https://github.com/Steffenhir/GraXpert/releases?page=1

    Thanks again for your help. This hasn't been the only program needing tweaking to get working on my PC.  I tried a couple of others over the last month for astronomy too.  Thankfully, other users with slow/ inadequate PCs were able to develop
    alternate program files to allow the master programs to work.  The big issue with those programs was that they normally wouldn't function on NON-AVX PCs (and mine of course is non-AVX), but they modified the programs to allow it.

    I can't find even a simple "onnxruntime DirectML Hello World" or
    a program which runs a "List Providers" sort of thing. I guess my
    GoogleFu isn't very good.

    In this example from July of this year, you can see a Dev is
    working with issues such as A+A (AMD CPU computation plus AMD ROCM or other computation)
    or I+N (which could be Intel GPU calc and/or NVidia GPU calc). The thing is, onnxruntime DirectML had its own "lazyload" at one time. This means, the bring-up code (that PyBind thing that is dying on yours), it would load
    an NVidia DLL, an Intel DLL, and so on, and build a provider list, and if
    the Dev wants it, "fuse" them together into one compute engine. Fusion
    might make the most sense, if you had identical models of GPU_0 and GPU_1.

    https://github.com/microsoft/onnxruntime/issues/13545

    The GraXpert program has its own (labeled) lazyload folder, implying
    it could be implementing lazyload after onnxruntime-DirectML removed it.

    https://nietras.com/2021/01/25/onnxruntime/

    In my previous encounters with this sort of issue (OpenCL), there was
    a user control you could set to CPU, or a branded GPU. And if the program mis-behaved, you'd simply edit the preference and change it back to the
    way it was. Or, keep the original Preferences file in a backup directory,
    and restore it if there was a failure.

    There's nothing wrong with the GraXpert dev doing Try-Catch around
    attempts to use various pieces of hardware. Even with the telemetry
    he is sucking from your machine, I doubt he will be able to make
    much sense out of all the hybrid test cases that real hardware
    throw up. Guys with $2000 GPUs and $2000 PCs, when they're doing
    development, they're unlikely to have $Broken-PC and $Broken-GPU
    to test against, where they can realize the program behaves poorly
    if left on full auto.

    If we had some kind of onnxruntime-DirectML that can do a HelloWorld
    on each hardware instance (your CPU for example, then test your GPU,
    noting which are failing and report to the user), this would be
    a marked improvement over the black-box the Dev is currently
    attempting to implment. Since the above Github indicates even as
    of July, the Try-Catch in the ONNX library doesn't work worth a darn,
    this tells you a decade later, this stuff *still* needs user assist
    and user-manual-controls. Not that stupid slider for "hardware acceleration", which is disingenuous. The situation just isn't that simple, to be
    pretending like that. I doubt the Dev really knows what the user
    experience is like on this Alpha code. I wouldn't say this, if it
    wasn't for my occasional exposure to programs like this, and
    what passes for Release code.

    The above Github entry, tells you that Devs, in an indirect way,
    are communicating their discomfort with the bad way that the
    manual control issue is handled. The Microsoft people making
    the ONNXruntime-DirectML work, it's hard to say whether they're
    working diligently on improving the automation. Normally Devs
    in that line of work, they expect the user to simply buy a
    $4000 PC to fix the errors their code throws :-/

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)