Autoruns

[Dex]

Microsoft have updated their SysInternals Autoruns to v14, I now get the
error 'Autoruns.exe - Ordinal Not Found - The ordinal 45 could not be
located in the dynamic link library Cabinet.dll.' when I try to run it.

Any ideas what I can do to get it to run?

[VanguardLH]

When I search on cabinet.dll, I find 20 of them. The two that are
important are under:

C:\Windows\System32
C:\Windows\SysWOW64

Do you find cabinet.dll there? I'm using Windows 10 Home x64 21H1. You
didn't mention what OS you are using. For me, right-clicking on the
file, select Properties, Details tab says:

Microsoft Cabinet File API
File version: 5.0.1.1
Date modified: 10/21/2020

"Ordinal not found"
https://www.ibm.com/support/pages/ordinal-could-not-be-located-dynamic-link-library-errors

Are you up to date with Windows Updates? Are you using an old and
unsupported version of Windows? Alas, the product page at
https://docs.microsoft.com/en-us/sysinternals/downloads/autoruns does
not list system requirements. Obviously it has some since it relies on
a system DLL. Could be the DLL is the wrong, old, or unsupported
version. Could be it is not in a path where the OS would look when a
program calls an exported function (method) in the DLL, and the program
relies on the registration of the DLL in the registry to find it rather
than the program specifying the absolute or relative path of where to
find the .dll file.

From the error message, it is unclear if the problem is the ordinal
(method index in the DLL) is undefined, missing, or corrupted, or if the
.dll file itself could not be found. Since a path is not mentioned to
the .dll file, the OS is going to look in the default locations: User
and System PATH environment variables (which are aggregated into the
PATH envvar you see using the 'set' command in a command shell),
registration of the .dll file (add registry entries pointing to it to
eliminate having to specify a path to the file), or in the current
folder for the shell in which the program was loaded. You could try to
re-register the .dll files, as in:

regsvr32.exe c:\windows\system32\cabinet.dll
regsvr32.exe c:\windows\syswow64\cabinet.dll

If re-registering doesn't work, first unregister the DLL by running:

regsvr32.exe /u <pathToFile>

See https://helpdeskgeek.com/how-to/register-dll-file-in-windows/. You
made no mention of the bitwidth of your Windows, or even which version
and edition of Windows (e.g., 7 Pro x86, 10 Home x64.

If re-registering the DLL file gets programs dependent on it to work
again, something messed with your OS setup. In that case, I'd do a full
image backup, and run "sfc.exe /scannow", or restore from a prior image
backup.

If you are using an old version of Windows, especially if unsupported,
you might have to revert back to an older version of Autoruns. When you
"installed" Autoruns.exe (which is just extracting from the .zip file to
deposit the archive's contents somewhere), where did you put the
contents of the .zip file? Did you extract all, or just the
autoruns.exe file?

Because C:\Program Files[ x64]\is a protected location (and why many old
games that deposit themselves under will fail to play or misbehave), and
for utilities, I created my own C:\Programs folder. Under there I
created a SysInternals subfolder, and under there a subfolder for each
tool from SysInternals, and it's that folder into which I dump the files
for each SysInternals' tool (e.g., C:\Programs\SysInternals\Autoruns).
Don't go polluting the system folders with your 3rd-party tools (the
tools themselves might still do that).

[p-0''0-h the cat (coder)]

What OS?

Are you running it from zip file or have you extracted it?

Live everyday like you're a cat.

Sent from my iFurryUnderbelly.

--
p-0.0-h the cat

Internet Terrorist, Mass sock puppeteer, Agent provocateur, Gutter rat,
Devil incarnate, Linux user#666, BaStarD hacker, Resident evil, Monkey Boy,
Certifiable criminal, Spineless cowardly scum, textbook Psychopath,
the SCOURGE, l33t p00h d3 tr0ll, p00h == lam3r, p00h == tr0ll, troll infâme,
the OVERCAT [The BEARPAIR are dead, and we are its murderers], lowlife troll,
shyster [pending approval by STATE_TERROR], cripple, sociopath, kook,
smug prick, smartarse, arsehole, moron, idiot, imbecile, snittish scumbag,
liar, total ******* retard, shill, pooh-seur, Pooh Dendum, scouringerer,
jumped up chav, punk ass dole whore troll, no nothing innumerate religious
maniac, lycanthropic schizotypal lesbian, professional bully and stalker,
the most complete ignoid, joker, and furball.

NewsGroups Numbrer One Terrorist

Honorary SHYSTER and FRAUD awarded for services to Haberdashery.
By Appointment to God Frank-Lin.

Signature integrity check
md5 Checksum: be0b2a8c486d83ce7db9a459b26c4896

I mark any messages from trolls »Q« and 'Arlene' Holder as stinky

[KenW]

https://autoruns.en.uptodown.com/windows/versions


KenW

[JJ]

Not possible.

The new version of Autoruns uses new Cabinet API functions which is
available only in Windows 8+.

Autoruns' support for Win7 is already matured and there's nothing else to
add. The newer Autoruns versions would be for Win8+ only - which still lack
of support.

Keep the old Autoruns version, because any new features in the newer version
of Autoruns won't be applicable in older Windows versions, anyway. Because
they're for Win8+ specific features.

Expect this to also happen to other Microsoft Internals tools in the future.

[VanguardLH]

JJ <jj4p...@gmail.com> wrote:

> Dex wrote:
>
>> Microsoft have updated their SysInternals Autoruns to v14, I now get
>> the error 'Autoruns.exe - Ordinal Not Found - The ordinal 45 could
>> not be located in the dynamic link library Cabinet.dll.' when I try
>> to run it.
>>
>> Any ideas what I can do to get it to run?
>
> Not possible.
>
> The new version of Autoruns uses new Cabinet API functions which is
> available only in Windows 8+.

That's why I was trying to find the system requirements for the MS
download page. Nope, they don't say. Since the tool just got updated,
and MS acquired SysInternals way back in 2006, and with MS dropping
support for anything pre-Windows 10, I figured MS made a change that
required some minimum version of Windows, but didn't want to make the
claim with no sysreqs listed. MS really should mention the minimum OS
version for what have been their tools for 15 years.

When MS drops support for an OS, they really chop up their site. URLs
to old KB pages for Windows XP have been long gone. I've hit some for
Windows 7 that are also gone (replaced or 404 page not found).

> Autoruns' support for Win7 is already matured and there's nothing else to
> add. The newer Autoruns versions would be for Win8+ only - which still lack
> of support.
>
> Keep the old Autoruns version, because any new features in the newer version
> of Autoruns won't be applicable in older Windows versions, anyway. Because
> they're for Win8+ specific features.
>
> Expect this to also happen to other Microsoft Internals tools in the future.

I've kept the old zip archive for SysInternalsSuite from 2019-04-04 and
for PSTools from 2016-07-04. Although I'm now on Windows 10 Home x64,
the old tools still work well. For me, the old Autoruns tools is
version 13.94.

Sometimes I can find old versions at oldversions.com. KenW mentioned a
site with old versions. 13.99 was released back around April 2021. The
next oldest they have is 13.3 released around Apr 2015. That's a 6-year
gap, so it looks like MS was mucking around with AutoRuns since 13.99,
with 14.0 being offered on their product page.

https://www.softpedia.com/progChangelog/AutoRuns-Changelog-21198.html
says the change in 14.0 was "to receive a UI overhaul including a dark
theme." For a tool like this, that was a complete waste of resources.

I couldn't find documentation from MS on cabinet.dll. I did find:

https://windows10dll.nirsoft.net/cabinet_dll.html

The exports indicate the methods that a process can call from the DLL.
Nothing pops out as relative to what AutoRuns does.

[Dex]

Bugger.

Oh well, I'll have to stick to an older version. Thanks for that.

[Yakker]

Dex <vai...@nospam.today> wrote in
news:sftgv5$4sb$1...@gioia.aioe.org:

Keep the old portable version before you try the update.
Not all features are working in the update (Win10).

--
Steve (--)

I filter using XNEWS.
If you expect a response and don't see it,
don't take it personally.

[p-0''0-h the cat (coder)]

On Mon, 23 Aug 2021 09:39:48 -0000 (UTC), Yakker <NoM...@IsGoodMail.com>
wrote:

>Keep the old portable version before you try the update.
>Not all features are working in the update (Win10).

Virustotal check didn't work for me. Pretty major feature for cats.

[Shadow]

On Sun, 23 Aug 2021 21:17:01 +0200, Mark Coffer
<mar...@nospam.invalid> wrote:

>Cabinet.dll is a Windows system DLL. You are running Windows 7. In
>Windows 7, cabinet.dll does not have the ordinal 45. That requires
>Windows 8 or later.
>
>It would seem that SysInternals Autoruns v14 is not made for your
>version of Windows (Windows 7).
>
>Two options to get it to run:
> A. Roll back SysInternals Autoruns to a version which is compatible
> with your OS, Windows 7.
> B. Update your OS to Windows 8 or to Windows 10.

I can only see one option. Use an older version of
Sysinternals.
Updating his OS will not help the OP see potentially unwanted
startups on his Win 7.
[]'s
--
Don't be evil - Google 2004
We have a new policy - Google 2012

[JJ]

On Mon, 23 Aug 2021 00:59:11 -0500, VanguardLH wrote:
>
> When MS drops support for an OS, they really chop up their site. URLs
> to old KB pages for Windows XP have been long gone. I've hit some for
> Windows 7 that are also gone (replaced or 404 page not found).

Microsoft simply want to bury older Windows versions, because they're bad
for business. The reason that older Windows is less secure is just one of
the reasons which can be used to suggest users into migrating to newer
Windows version.

> I've kept the old zip archive for SysInternalsSuite from 2019-04-04 and
> for PSTools from 2016-07-04. Although I'm now on Windows 10 Home x64,
> the old tools still work well.

Most of them, yes. Although not all Win8+ specific functions can be applied
to a tool either because they're irrelevant or just not applicatible,
there's no guarantee that Microsoft will use them as a way to force users to
migrate to newer Windows version. Similar to how simple applications such as
Win8+ Notepad are made unrunable in Win7, or Win7+ Notepad which is made
unrunable in Vista.

For my research of the CMD tool, I've already successfully patched Win8,
Win8.1, and all Win10 builds of the CMD tool to make it runable in Win7
again. It made me question why Microsoft did it in the first place.

> Sometimes I can find old versions at oldversions.com. KenW mentioned a
> site with old versions. 13.99 was released back around April 2021. The
> next oldest they have is 13.3 released around Apr 2015. That's a 6-year
> gap, so it looks like MS was mucking around with AutoRuns since 13.99,
> with 14.0 being offered on their product page.

Most of old versions of a software can still be retrieved from the Internet
Archive's Wayback Machine. Microsoft's included. It's just a pity that
Internet Archive doesn't include FTP sites, cause I'd like to get some old
files from big boys' FTP sites such as Microsoft, IBM, Apple, Adobe, etc.

> https://www.softpedia.com/progChangelog/AutoRuns-Changelog-21198.html
> says the change in 14.0 was "to receive a UI overhaul including a dark
> theme." For a tool like this, that was a complete waste of resources.

Very true. And because of that, Process Monitor's log highlighting feature
has been broken and ineffective, while the older version still works fine.
At least when run in Win7. Though, the older version may freeze the system
sometimes.

> I couldn't find documentation from MS on cabinet.dll. I did find:
>
> https://windows10dll.nirsoft.net/cabinet_dll.html
>
> The exports indicate the methods that a process can call from the DLL.
> Nothing pops out as relative to what AutoRuns does.

The new API function which is used by the new version of Autoruns is
Decompressor related functions. e.g. `CreateDecompressor()`.

If you take a look at that function's documentation in Microsoft site,
you'll see that its minimum required OS is Win8. (long text warning)

https://docs.microsoft.com/en-us/windows/win32/api/compressapi/nf-compressapi-createdecompressor#requirements

And if you use Microsoft's Dependendy Walker tool, you'll see that the
`CloseDecompressor()` function's ordinal (or ID number) is 45.

https://i.imgur.com/hucpS45.jpg

I know what those functions are for, but I don't know what it's used for in
Autoruns, cause AFAIK, Autoruns don't need to look into CAB files. If it's
used to support the new Win10 NTFS compression, the decompression should
already be transparently done by the NTFS driver.

There's a possibility that a file listed in Autoruns is stored in a drive
which came from Win10 system and the file uses the new Win10 compression,
but why would the file be part of autorun application/module when the (Win8
and older) NTFS driver itself isn't capable of decompressing the file in the
first place? That one more question for Microsoft.

[Mark Coffer]

If the OP updates his/her OS then it will not be Win 7 any more. It will
become a later version of Windows.


Whether the OP wants to do this is the OP's choice.

[VanguardLH]

JJ <jj4p...@gmail.com> wrote:

> VanguardLH wrote:
>
>> Sometimes I can find old versions at oldversions.com. KenW mentioned a
>> site with old versions.
>

> Most of old versions of a software can still be retrieved from the Internet
> Archive's Wayback Machine.

The archived copy of a web page will have the hyperlink, but it's
useless unless it points to a still-existing page or file to do the
download. I've used web.archive.org a lot to see old docs, but too
often the URLs to files are dead. The site didn't just remove the web
page. They also removed the index to the file or the file itself. I'ts
one of those it-might-work-but-it-might-not. Depends on how well a site
admin does the cleanup.

> Though, the older version [of SysInternals' Process Monitor] may
> freeze the system sometimes.

I only had that if I left ProcMon running. I'd forget about it, and it
kept adding to its log. ProcMon records everything. You can filter the
log to see what you want, but everything is still getting recorded (so,
for example, you could change the filter for a different view of the
log). As the log kept getting bigger, eventually it gets so big that
the constant updating slows the OS perhaps due to I/O throttling. I'd
go into ProcMon, disable the logging, and, voila, the OS became
responsive again. It's great for monitoring, but not for long periods.

>> https://windows10dll.nirsoft.net/cabinet_dll.html
>> The exports indicate the methods that a process can call from the DLL.
>> Nothing pops out as relative to what AutoRuns does.
>
> The new API function which is used by the new version of Autoruns is
> Decompressor related functions. e.g. `CreateDecompressor()`.

Yet Autoruns is just telling which are the startup programs, and from
where. It's not reading into those files, so why would a decompressor
function be needed? Yeah, cabinet files are compressed, but not the
startup programs themselves, and certainly not their filenames. Maybe
reading into a file used as a startup program is a feature that I've
never used in AutoRuns, but I wouldn't use it, anyway. If I see Joe is
starting up, I don't care if Joe is a guy, gal, straight, gay, tall,
short, or what he was, just that Joe is starting up. If I wanted to
look inside a startup program, I'd use WordPad (still useful to see
strings), HxD (hex editor), or something else to look inside the file.

> I know what those functions are for, but I don't know what it's used
> for in Autoruns, cause AFAIK, Autoruns don't need to look into CAB
> files.

A .cab file is not a startable program, so it cannot be a startup
program. It's not like a .dll that could be startable if it has a
main() method. I know rundll32.exe can be used to fall a method from a
DLL, but I don't remember seeing a similar trick of calling an
exectuable from within a CAB file, but that doesn't mean there isn't
one, and I'm not much into Powershell to see if that could be used to
extract and run an .exe from within a .cab, but a script could be made
to do that.

> If it's
> used to support the new Win10 NTFS compression, the decompression should
> already be transparently done by the NTFS driver.

That's what I figured. If you enable NTFS compression, it's on the file
system, and should be transparent.

> There's a possibility that a file listed in Autoruns is stored in a
> drive which came from Win10 system and the file uses the new Win10
> compression, but why would the file be part of autorun
> application/module when the (Win8 and older) NTFS driver itself isn't
> capable of decompressing the file in the first place? That one more
> question for Microsoft.

More likely Microsoft created the dependency in autoruns.exe to
cabinet.dll without any real dependency. They could add a call to
CreateDecompressor() without actually using it; i.e., dummy code. That
would force their tools to demand a version of Windows that was still
supported, or, at least, not support a version of Windows that was too
old to bundle the DLL. However, you'd think they simply check for the
OS version, and puke out a bogus error saying the tool wouldn't work
under a version older than, say, Win8.

Or, since this is a new version of AutoRuns, could be a developer fucked
up the code, was going to add something, but never got to whatever he
was going to add. I've seen this in Dev when programmers get some free
time, and when they get dangerous. They start adding stuff that was not
in either the Functional or Engineering specs, QA finds it and has to
allocate time to test the new feature (that no customer requested, and
adds no value), or QA talks to the Dev manager why something was added
that wasn't in the specs, so it gets removed (revert back to a code
branch). New code can fix old problems, but it can introduce new
problems, too. That's why I don't update hardware drivers unless a new
version really does fix an old problem that I actually encounter, or
adds a feature that I really do want; else, a driver that is working
doesn't need to get replaced.

[Mike Dee]

JJ wrote:

> Most of old versions of a software can still be retrieved from the
> Internet Archive's Wayback Machine. Microsoft's included. It's
> just a pity that Internet Archive doesn't include FTP sites, cause
> I'd like to get some old files from big boys' FTP sites such as
> Microsoft, IBM, Apple, Adobe, etc.

Not "most" more like "quite a lot" ;-)

You can find some "big boys" FTP sites collected at the Internet
Archive, by visiting the "FTP Site Boneyard":
<https://archive.org/details/ftpsites>

You never know what you can find in here (hit and miss)

--
dee

[David Brooks]

Have you ever been here?

http://web.archive.org/web/20210306015347/http://dogagent.com/nindex.html

[Shadow]

Interesting, but some of the tar'd sites are 200-300GB
downloads
Too much for my connection(and HD - I have around 2 GB spare,
but that's for important Pr0n)

[]'s

--
Don't be evil - Google 2004
We have a new policy - Google 2012

Google Fuchsia - 2021

[Mike Dee]

Shadow wrote:

> On Wed, 25 Aug 2021 23:08:13 -0000 (UTC), Mike Dee
> <mik...@emteedee.invalid> wrote:
>
>>JJ wrote:
>>
>>> Most of old versions of a software can still be retrieved from the
>>> Internet Archive's Wayback Machine. Microsoft's included. It's
>>> just a pity that Internet Archive doesn't include FTP sites, cause
>>> I'd like to get some old files from big boys' FTP sites such as
>>> Microsoft, IBM, Apple, Adobe, etc.
>>
>>Not "most" more like "quite a lot" ;-)
>>
>>You can find some "big boys" FTP sites collected at the Internet
>>Archive, by visiting the "FTP Site Boneyard":
>><https://archive.org/details/ftpsites>
>>
>>You never know what you can find in here (hit and miss)
>
> Interesting, but some of the tar'd sites are 200-300GB
> downloads
> Too much for my connection(and HD - I have around 2 GB spare,
> but that's for important Pr0n)

Wow it will have to be important if you only have 2GB to spare ;-)

Yes the archives can be huge and off-putting. But...

On an archived FTP site of interest, under "Download Options"

Click "Show All"
In the following page, locate the main download (zip or tar) name
and click the "View Contents" link attached to the file name.

Now, depending on the size of the archive and your connection speeds
this may take a while to show up. Once it does though, you can view
what inside of the archive, and better, download any item individually
without needing to download the entire archive of mostly unwanted
content.

--
dee

[JJ]

On Wed, 25 Aug 2021 23:08:13 -0000 (UTC), Mike Dee wrote:
>
> You can find some "big boys" FTP sites collected at the Internet
> Archive, by visiting the "FTP Site Boneyard":
> <https://archive.org/details/ftpsites>

Thanks. That went into my bookmarks nicely.

> You never know what you can find in here (hit and miss)

I noticed. The archived Microsoft FTP doesn't include MS-DOS knowledge base
documents. No archive for `ftp.apple.com` too. Only `developer.apple.com`.

But, dang! It took minutes to actually start receiving the content list data
of a 60GB TAR from the server. They should use a list cache for browsable
file contents, so that at least, it won't hog server computing time.

[Mike Dee]

"No archive for `ftp.apple.com`"

"download.info.apple.com" perhaps ? Two copies of this I can see
both of different sizes:

<https://archive.org/details/download.info.apple.com.2012.11>

<https://archive.org/details/ftpsites_download.info.apple.com>

--
dee

[JJ]

On Thu, 26 Aug 2021 13:28:05 -0000 (UTC), Mike Dee wrote:
>
> "No archive for `ftp.apple.com`"
>
> "download.info.apple.com" perhaps ? Two copies of this I can see
> both of different sizes:
>
> <https://archive.org/details/download.info.apple.com.2012.11>
>
> <https://archive.org/details/ftpsites_download.info.apple.com>

I could be wrong. It may have been `download.info.apple.com` all along. I've
accessed the FTP site a long time ago, so I've forgotten the exact host
name.

But that is the correct FTP site. Thank you.

[Dex]

On 23/08/2021 06:07, JJ wrote:

Autoruns v14.01 seems to be working OK on Win7 again, it was probably a bug.