On 11/17/24 6:10 PM, Jackson Durmott wrote:I then tried an advanced start up and when restarted, all I am presented with is an option to turn off the PC.
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.
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.
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,
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 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.
On 11/18/24 11:54 AM, Paul wrote: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
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
be found."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.
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
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 BIOSsettings, 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, butstill 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
With a prior version, the preferences.json file was present, but not in the latest version that I am usinghardware acceleration in notepad.
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
The only file indicating preferences is one called preferences.pyc which I read is non-editable unless using source code.it looks like something gamers uses.
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
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.
preferences.json in the GraXpert folder. When I tried starting GraXpert, however, same error: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
https://tinyurl.com/68694f7p
On 11/21/24 12:39 AM, Paul wrote:preferences.json in the GraXpert folder. When I tried starting GraXpert, however, same error:
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
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.
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.
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.
On 11/22/24 1:05 AM, Paul wrote: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
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
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, eventhough 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
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 .onnxformat for their models.
https://github.com/Steffenhir/GraXpert/releases?page=1alternate 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.
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
On 11/22/24 1:05 AM, Paul wrote: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
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
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, eventhough 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
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 .onnxformat for their models.
https://github.com/Steffenhir/GraXpert/releases?page=1alternate 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.
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
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 508 |
Nodes: | 16 (1 / 15) |
Uptime: | 238:16:47 |
Calls: | 9,985 |
Calls today: | 3 |
Files: | 13,836 |
Messages: | 6,358,233 |