[Check-in bc3bf7c6](https://sqlite.org/src/info/bc3bf7c6681a96bc) appears to be intended as a fix for the subject bug, but it does not work as intended.
The hunt for beginning of the DLL basename when SQLITE\_OS\_WIN is true now reads:
```
for(iFile=ncFile-1; iFile>=0 && ((c=zFile[iFile]!='/')||c=='\\'); iFile--){}
```
This has two problems: (1) The search should stop, rather than continue, when the usual Windows path separator '\\' is found; and (2) the value of c becomes the boolean result of the comparison to '/', which is always false when the comparison to '\\\\' is reached thus being equivalent to 0=='\\\\' for that test.
The intent of that code would be better expressed with this replacement:
```
for(iFile=ncFile-1; iFile>=0 && (c=zFile[iFile])!='/'&&c!='\\'; iFile--){}
```
I have built and tested both versions with these shell commands, (where the shell executable is not located in /Bin), with results as noted:
```
.load /Bin/natsort
.load \\Bin\\natsort sqlite3_natsort_init
These two succeed for all versions.
.load \\Bin\\natsort
This fails with "Error: The specified procedure could not be found." for check-in bc3bf7c6 (and earlier versions) and succeeds with the proposed replacement.
```