[GRASS-user] g.list ... -1073741701

GRASS GRASS user
1

I understand that this is where one may come with one's GRASS problems;
please, someone, correct me if I have got it wrong.

I seem to have just installed GRASS 7.2.1 under Windows XP along with
the spearfish60_grass7. An attempt to start a session with
(spearfish...,user1) gets return code -1073741701;
the g.list test does not get any complaint about sqlite3.dll
(the message mentions 0xc000007b) but I have tried hiding competing
sqlite3.dlls anyway - to no avail.

What might the matter be?

Edmund

2

On Mon, Aug 14, 2017 at 3:26 AM, Edmund Swylan
<Edmund.Swylan@ponymail.com> wrote:

I understand that this is where one may come with one's GRASS problems;
please, someone, correct me if I have got it wrong.

All fine, welcome here!

I seem to have just installed GRASS 7.2.1 under Windows XP along with
the spearfish60_grass7. An attempt to start a session with
(spearfish...,user1) gets return code -1073741701;
the g.list test does not get any complaint about sqlite3.dll
(the message mentions 0xc000007b) but I have tried hiding competing
sqlite3.dlls anyway - to no avail.

Searching in the net I found the hint that there may be a mixup of
64bit and 32bit DLLs:

Similar issues:
https://stackoverflow.com/questions/11648621/c-sdl-native-has-exited-with-code-1073741701-0xc000007b
https://stackoverflow.com/questions/32990900/opencv-and-qt-exit-code-1073741701

What might the matter be?

Could you please check if you got any 64bit DLL in the way? I suppose
that your XP installation is a 32bit system.

Markus

--
Markus Neteler, PhD
http://www.mundialis.de - free data with free software
http://grass.osgeo.org
http://courses.neteler.org/blog

3

ES> I seem to have just installed GRASS 7.2.1 under Windows XP along with
ES> the spearfish60_grass7. An attempt to start a session with
ES> (spearfish...,user1) gets return code -1073741701;
ES> the g.list test does not get any complaint about sqlite3.dll
ES> (the message mentions 0xc000007b) but I have tried hiding competing
ES> sqlite3.dlls anyway - to no avail.

MN> Searching in the net I found the hint that there may be a mixup of
MN> 64bit and 32bit DLLs:
MN> Similar issues:
MN> https://stackoverflow.com/questions/11648621/c-sdl-native-has-exited-with-code-1073741701-0xc000007b
MN> https://stackoverflow.com/questions/32990900/opencv-and-qt-exit-code-1073741701
MN> Could you please check if you got any 64bit DLL in the way? I suppose
MN> that your XP installation is a 32bit system.

Dear Markus,

Thank you very much for your response.

Yes, the XP installation is 32 bit.

I have made sure that the sqlite3.dll from the ...\extrabin and no other
gets used by renaming this squlite3.dll and getting it reported as missing.
I have tried three sqlite3.dlls from my collection and got the -1073741701
in all cases. At least one of the three works as expected in other contexts.
I have observed that the sqlite3.dll in WinGRASS-7.2.1-1-Setup-x86.exe
is the biggest of the lot though not the newest.

I have also tried - for the first time - a GRASS 7.2.0 that came with
QGIS 2.14 (and two sqlite.dlls: one QGIS 2.14's and another for saga);
-1073741701.

Perhaps another .dll is to blame? Which .dlls might be relevant and
- probably - not used by SQLite in non-spatial contexts?

Edmund

4

ES> I seem to have just installed GRASS 7.2.1 under Windows XP along with
ES> the spearfish60_grass7. An attempt to start a session with
ES> (spearfish...,user1) gets return code -1073741701;
ES> the g.list test does not get any complaint about sqlite3.dll
ES> (the message mentions 0xc000007b) but I have tried hiding competing
ES> sqlite3.dlls anyway - to no avail.
MN> Searching in the net I found the hint that there may be a mixup of
MN> 64bit and 32bit DLLs: ...

Dear Markus,

I have retried the experiment with GRASS 7.0.5. The end result is the same,
but the mentions of various lines in .pys and the -1073741701 are preceded
by several `Numeric,numarray or Numpy not found. This module requires ...'
paragraphs. The rest can be seen, e.g., in
https://stackoverflow.com/questions/38568072/trouble-importing-numpy-into-grass-gis-7-0-on-windows-10 .
And there is no shortage of bad Numpy items in
http://trac.osgeo.org/grass/search?q=numpy .
I do not keep any pythons around - apart from those brought in by
the stand-alone GRASS installer(s); perhaps the installer has not brought
in as many as it should have?

Yours,

Edmund

5

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/g-list-1073741701-tp5331416p5331495.html
Sent from the Grass - Users mailing list archive at Nabble.com.

6

Edmund Swylan wrote

I seem to have just installed GRASS 7.2.1 under Windows XP along with
the spearfish60_grass7. An attempt to start a session with
(spearfish...,user1) gets return code -1073741701;
the g.list test does not get any complaint about sqlite3.dll
(the message mentions 0xc000007b) but I have tried hiding competing
sqlite3.dlls anyway - to no avail.

[pushed the send button too early]

which winGRASS version do you use? OSGeo4W-winGRASS or standalone winGRASS
installer?

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/g-list-1073741701-tp5331416p5331496.html
Sent from the Grass - Users mailing list archive at Nabble.com.

7

HK> which winGRASS version do you use? OSGeo4W-winGRASS or standalone winGRASS
HK> installer?

Dear Helmut,

By now 7.2.1, 7.2.0, and 7.0.5 have participated. The 7.2.1 and the 7.0.5
have been installed by WinGRASS-7.2.1-1-Setup-x86.exe and
WinGRASS-7.0.5-1-Setup-x86.exe respectively. 7.2.0 got installed with
QGIS 2.14. All three give lists of .pys line numbers (some fifteen of them)
and then
`grass.exceptions.CalledModuleError: Module run None ['g.list', '--q', '-m', 'typ
e=raster'] ended with error
Process ended with non-zero return code -1073741701. See errors in the (error) o
utput.'
7.0.5 precedes this with four "NumPy paragraphs".
GRASS reports my operating system as `Version 5.1.2600'; I know it as
`Version 2002 with Service Pack 3'.

Yours,

Edmund

8

Edmund Swylan wrote

HK> which winGRASS version do you use? OSGeo4W-winGRASS or standalone
winGRASS
HK> installer?

Dear Helmut,

By now 7.2.1, 7.2.0, and 7.0.5 have participated. The 7.2.1 and the 7.0.5
have been installed by WinGRASS-7.2.1-1-Setup-x86.exe and
WinGRASS-7.0.5-1-Setup-x86.exe respectively. 7.2.0 got installed with
QGIS 2.14. All three give lists of .pys line numbers (some fifteen of
them)
and then
`grass.exceptions.CalledModuleError: Module run None ['g.list', '--q',
'-m', 'typ
e=raster'] ended with error
Process ended with non-zero return code -1073741701. See errors in the
(error) o
utput.'
7.0.5 precedes this with four "NumPy paragraphs".
GRASS reports my operating system as `Version 5.1.2600'; I know it as
`Version 2002 with Service Pack 3'.

Yours,

Edmund

_______________________________________________
grass-user mailing list

grass-user@.osgeo

https://lists.osgeo.org/mailman/listinfo/grass-user

Do you have grass addons installed?

All three give lists of .pys line numbers (some fifteen of them)

Could you post all the lines here?

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/g-list-1073741701-tp5331416p5331523.html
Sent from the Grass - Users mailing list archive at Nabble.com.

9

Edmund Swylan wrote

HK> which winGRASS version do you use? OSGeo4W-winGRASS or standalone
winGRASS
HK> installer?

Dear Helmut,

By now 7.2.1, 7.2.0, and 7.0.5 have participated. The 7.2.1 and the 7.0.5
have been installed by WinGRASS-7.2.1-1-Setup-x86.exe and
WinGRASS-7.0.5-1-Setup-x86.exe respectively. 7.2.0 got installed with
QGIS 2.14. All three give lists of .pys line numbers (some fifteen of
them)
and then
`grass.exceptions.CalledModuleError: Module run None ['g.list', '--q',
'-m', 'typ
e=raster'] ended with error
Process ended with non-zero return code -1073741701. See errors in the
(error) o
utput.'
7.0.5 precedes this with four "NumPy paragraphs".
GRASS reports my operating system as `Version 5.1.2600'; I know it as
`Version 2002 with Service Pack 3'.

Yours,

Edmund

_______________________________________________
grass-user mailing list

grass-user@.osgeo

https://lists.osgeo.org/mailman/listinfo/grass-user

Do have activated to install also the MS runtimes by the winGRASS standalone
installer?

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/g-list-1073741701-tp5331416p5331524.html
Sent from the Grass - Users mailing list archive at Nabble.com.

10

Dear Helmut,

HK> Do you have grass addons installed?

No.

ES>All three give lists of .pys line numbers (some fifteen of them)
HK> Could you post all the lines here?

The screen shots might be too much for the list; I will send them just to you.

HK> Do have activated to install also the MS runtimes by the winGRASS standalone
HK> installer?

The MSVC*.dlls? Yes. My C:\WINDOWS\SYSTEM32 now has the following MSVC*.dlls:

14/04/2008 12:00 57,344 msvcirt.dll
18/03/2010 09:15 421,200 msvcp100.dll
05/10/2013 02:38 455,328 msvcp120.dll
17/03/2016 22:48 443,712 msvcp140.dll
14/04/2008 12:00 565,760 msvcp50.dll
14/04/2008 12:00 413,696 msvcp60.dll
18/03/2010 09:15 770,384 msvcr100.dll
05/10/2013 02:38 970,912 msvcr120.dll
14/04/2008 12:00 343,040 msvcrt.dll
14/04/2008 12:00 253,952 msvcrt20.dll
14/04/2008 12:00 61,440 msvcrt40.dll

The extrabins of GRASS 7.2.1 and GRASS 7.0.5 each has

13/07/2005 02:50 401,462 msvcp60.dll
13/07/2005 02:50 487,424 msvcp70.dll
10/11/2005 22:48 499,712 msvcp71.dll
10/11/2005 22:48 348,160 msvcr71.dll
13/07/2005 02:50 343,040 msvcrt.dll

Yours,

Edmund

11

Edmund Swylan wrote

ES> I seem to have just installed GRASS 7.2.1 under Windows XP along with
ES> the spearfish60_grass7. An attempt to start a session with
ES> (spearfish...,user1) gets return code -1073741701;
ES> the g.list test does not get any complaint about sqlite3.dll
ES> (the message mentions 0xc000007b) but I have tried hiding competing
ES> sqlite3.dlls anyway - to no avail.

MN> Searching in the net I found the hint that there may be a mixup of
MN> 64bit and 32bit DLLs:
MN> Similar issues:
MN>
https://stackoverflow.com/questions/11648621/c-sdl-native-has-exited-with-code-1073741701-0xc000007b
MN>
https://stackoverflow.com/questions/32990900/opencv-and-qt-exit-code-1073741701
MN> Could you please check if you got any 64bit DLL in the way? I suppose
MN> that your XP installation is a 32bit system.

Dear Markus,

Thank you very much for your response.

Yes, the XP installation is 32 bit.

I have made sure that the sqlite3.dll from the ...\extrabin and no other
gets used by renaming this squlite3.dll and getting it reported as
missing.
I have tried three sqlite3.dlls from my collection and got the -1073741701
in all cases. At least one of the three works as expected in other
contexts.
I have observed that the sqlite3.dll in WinGRASS-7.2.1-1-Setup-x86.exe
is the biggest of the lot though not the newest.

I have also tried - for the first time - a GRASS 7.2.0 that came with
QGIS 2.14 (and two sqlite.dlls: one QGIS 2.14's and another for saga);
-1073741701.

Perhaps another .dll is to blame? Which .dlls might be relevant and
- probably - not used by SQLite in non-spatial contexts?

tested here on an old winXP 32bit box, unfortunately I can't reproduce the
error; everything works ok.

----
GRASS version: 7.2.1
GRASS SVN revision: r71013
Build date: 2017-05-03
Build platform: i386-w64-mingw32
GDAL: 2.1.3
PROJ.4: 4.9.3
GEOS: 3.5.0
SQLite: 3.17.0
Python: 2.7.4
wxPython: 2.8.12.1
Platform: Windows-Vista-6.0.6002-SP2

typing following in the winGRASS windows console:

C:\Users\normal>where sqlite3.dll
C:\Program Files\GRASS GIS 7.2.1\extrabin\sqlite3.dll

----

GRASS version: 7.2.1
GRASS SVN revision: r71013
Build date: 2017-05-03
Build platform: i386-w64-mingw32
GDAL: 2.1.3
PROJ.4: 4.9.3
GEOS: 3.5.0
SQLite: 3.17.0
Python: 2.7.4
wxPython: 2.8.12.1
Platform: Windows-Vista-6.0.6002-SP2 (OSGeo4W)

typing following in the winGRASS windows console:

C:\>where sqlite3.dll
C:\OSGeo4W\bin\sqlite3.dll

----

and then in a normal windows console provided by the operating system:

C:\Users>where sqlite3.dll
INFORMATION: No file could be found

----

(1) could you open a normal windows console provided by the operating system
and type:

where sqlite3.dll

and post the result

(2) could you try the OSGeo4W-winGRASS [A] without any change in your
settings or files in the OSGeo4W-winGRASS installation and try winGRASS
there; type 'where sqlite3.dll' in the OSGeo4W-windows console

(3) and as Markus suggested in the other mail: try Dependency Walker to
check dll-dependencies

(4) any chance to use another windows box than winXP?

[A] https://trac.osgeo.org/osgeo4w/

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/g-list-1073741701-tp5331416p5331879.html
Sent from the Grass - Users mailing list archive at Nabble.com.

12

Dear Helmut,

HK> (1) could you open a normal windows console provided by the operating system
HK> and type: where sqlite3.dll
HK> and post the result

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\es>cd ..\..

C:\>where sqlite3.dll
'where' is not recognized as an internal or external command,
operable program or batch file.

C:\>

But ... I believe that sqlite3.dll is the one .dll I have dealt with.

HK> (2) could you try the OSGeo4W-winGRASS [A] without any change in your
HK> settings or files in the OSGeo4W-winGRASS installation and try winGRASS
HK> there; type 'where sqlite3.dll' in the OSGeo4W-windows console

Maybe. But, surely, a network installer has more, not fewer, options than
a stand-alone one?

HK> (3) and as Markus suggested in the other mail: try Dependency Walker to
HK> check dll-dependencies

Done ... to an extent.

HK> (4) any chance to use another windows box than winXP?

I have a 95 and several versions of 98.

HK> the dll-issues looks like a mismatch and mixing of dlls and their
HK> dependencies in %PATH% variable.

Yes. And that is why I think I stand a slightly better chance with 6.4.4
whose PATH seems to be set by three .bats and not by a GRASS...py.

HK> AFAICT starting from scratch may be an option.

What's scratch? Uninstalling all GRASSes and killing the remaining weeds
in, say, Documents and Settings? Has been - almost - done once or twice.
`Almost', since I did not weed out the stuff "within" QGIS.

I have also done a 7.2.1 (and Spearfish) installation on another (XP)
computer - one without any SQLite or QGIS. Same result.

Since
(1) in your experiment the problem has not arisen, and
(2) all GRASS specific .dlls (should) occur on the PATH before their
    possible competitors,
it would seem that there is an indispensable .dll which is not part of
the GRASS distribution and which I have not or have an unsuitable version
of. The DependencyWalker has already come up with EFSADU.dll and MSJAVA.dll.
The former can hardly be indispensable, the latter I have now introduced
into C:\WINDOWS\system32. Unsuitable versions are more difficult.

Yours,

Edmund

13

C:\>where sqlite3.dll
'where' is not recognized as an internal or external command,
operable program or batch file.

sorry, the where command is available in >= WinVista

the latter I have now introduced into C:\WINDOWS\system32.

it's not recommended (and normally not needed) to change anything by user
directly in the operating systems folder like C:\WINDOWS\system32. too much
risk for mixing and messing up things.

I have a 95 and several versions of 98.

no newer ones?

I have also done a 7.2.1 (and Spearfish) installation on another (XP)
computer - one without any SQLite or QGIS. Same result.

I've co-developed the winGRASS-installers up from the beginning, we tested
it quite a lot on different windows versions and flavors in this long time.

Yes. And that is why I think I stand a slightly better chance with 6.4.4
whose PATH seems to be set by three .bats and not by a GRASS...py.

AFAICT there is no fundamental difference in setting %PATH% between the
winGRASS 6.x and winGRASS 7.x line.

What's scratch? Uninstalling all GRASSes and killing the remaining weeds
in

yes

Maybe. But, surely, a network installer has more, not fewer, options than
a stand-alone one?

the standalone installer is based upon the OSGeo4W-environment; there it's
possible to add step by step new components, e.g.

- first, install only the basic OSGeo4W-environment, which is mostly
GDAL/PROJ4 stuff, which is GRASS based upon
- do some tests, e.g. by ogrinfo yourshapefile.shp, gdalinfo yourgeo.tif,
ogr2ogr newshapefile.shp oldshapefile.shp etc etc
- add winGRASS to the OSGeo4W-environment and do some tests.

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/g-list-1073741701-tp5331416p5331910.html
Sent from the Grass - Users mailing list archive at Nabble.com.

14

Dear Helmut,

HK> it's not recommended (and normally not needed) to change anything by user
HK> directly in the operating systems folder like C:\WINDOWS\system32. too much
HK> risk for mixing and messing up things.

This might be a matter of one's view of the world. As we know, things get messed
up under all policies. Tastes in messes differ.

To return to the case in hand, the system directories of the other computer
have been modified only indirectly, i.e., by installations.

ES> I have a 95 and several versions of 98.
HK> no newer ones?

At the moment I would not be interested in a GRASS under a Windows newer than
all XPs.

HK> I've co-developed the winGRASS-installers up from the beginning, we tested
HK> it quite a lot on different windows versions and flavors in this long time.

There is nothing reprehensible in an application depending on, say, a .dll
that Microsoft, or the author of another application, or the "user" may have
modified or removed. But one feels encouraged if there is a way of guessing
which .dll it might be. Does, say, v.info indeed depend on numerous external
functions? Hasn't its developer a good idea what it depends on? I can try
things out with various versions of several .dlls, risk of mess or not.

HK> the standalone installer is based upon the OSGeo4W-environment; there it's
HK> possible to add step by step new components, e.g.
HK> - first, install only the basic OSGeo4W-environment, which is mostly
HK> GDAL/PROJ4 stuff, which is GRASS based upon
HK> - do some tests, e.g. by ogrinfo yourshapefile.shp, gdalinfo yourgeo.tif,
HK> ogr2ogr newshapefile.shp oldshapefile.shp etc etc
HK> - add winGRASS to the OSGeo4W-environment and do some tests.

How would the problem in hand disappear thanks to the removal of some parts
of the environment established by the stand-alone installer? Perhaps the
Spearfish is too fat for the experiments? Maybe I should reinstall a GRASS
without the fish and try a function or two on a small .shp? Maybe you have
a particular .shp in mind?

Yours,

Edmund

15

This might be a matter of one's view of the world

But we in GRASS ML aren't able to help when operating system folders and
files have been eventually changed.

How would the problem in hand disappear thanks to the removal >of some

parts

of the environment established by the stand-alone installer?

Nothing dissapears, but it helps to cut it down if it's GRASS or some other
software shipped by the underlying OSGeo4W environment causes this error;
there may be different sources for the issue, E.g. Gdal, sqlite or anything
else misses some MS runtimes or other things, mixup and interefering of
different dll versions, there are more python installations which interfere,
antivirus software is somewhere in the middle etc etc.

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/g-list-1073741701-tp5331416p5331919.html
Sent from the Grass - Users mailing list archive at Nabble.com.

16

Dear Helmut,

I may have discovered the immediate cause of my 0xc000007b.
I have been investigating winGRASS 6.4.4, but the deduced remedy works
for winGRASS 7.2.1 as well.

The setting of PATH looks peculiar even at the beginning.
From some later point on the order of searching for a .dll seems to be

%GISBASE%\bin
C:\WINDOWS\system32
C:\WINDOWS\system
C:\WINDOWS
%APPDATA%\..
%GISBASE%\bin
%GISBASE%\lib
%APPDATA%\GRASS6\addons (In my case this path does not exist.)
%GISBASE%\bin
%GISBASE%\extrabin

It is awkward, but it works as long as, say, system32 does not contain
an unsuitable version of a .dll, whose expected version is, say, in
extrabin. In my case this happens with libtiff.dll.

extrabin has libtiff dll│411136│16/06/12 .
system32 has libtiff dll│546816│07/03/16 .

Renaming the system32 version to libtiff1.dll lets the v.info soils
in winGRASS 6.4.4 with Spearfish come up with a reasonable output.
It also lets winGRASS 7.2.1 with Spearfish start a GUI.

Yours,

Edmund

17

Edmund Swylan wrote

Dear Helmut,

I may have discovered the immediate cause of my 0xc000007b.
I have been investigating winGRASS 6.4.4, but the deduced remedy works
for winGRASS 7.2.1 as well.

The setting of PATH looks peculiar even at the beginning.
From some later point on the order of searching for a .dll seems to be

%GISBASE%\bin
C:\WINDOWS\system32
C:\WINDOWS\system
C:\WINDOWS
%APPDATA%\..
%GISBASE%\bin
%GISBASE%\lib
%APPDATA%\GRASS6\addons (In my case this path does not exist.)
%GISBASE%\bin
%GISBASE%\extrabin

It is awkward, but it works as long as, say, system32 does not contain
an unsuitable version of a .dll, whose expected version is, say, in
extrabin. In my case this happens with libtiff.dll.

extrabin has libtiff dll│411136│16/06/12 .
system32 has libtiff dll│546816│07/03/16 .

Renaming the system32 version to libtiff1.dll lets the v.info soils
in winGRASS 6.4.4 with Spearfish come up with a reasonable output.
It also lets winGRASS 7.2.1 with Spearfish start a GUI.

Yours,

Edmund

_______________________________________________
grass-user mailing list

grass-user@.osgeo

https://lists.osgeo.org/mailman/listinfo/grass-user

Glad to see that you've found the interfering dll

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/g-list-1073741701-tp5331416p5332189.html
Sent from the Grass - Users mailing list archive at Nabble.com.

18

ES> %GISBASE%\bin
ES> C:\WINDOWS\system32
ES> C:\WINDOWS\system
ES> C:\WINDOWS
ES> %APPDATA%\..
ES> %GISBASE%\bin
ES> %GISBASE%\lib
ES> %APPDATA%\GRASS6\addons (In my case this path does not exist.)
ES> %GISBASE%\bin
ES> %GISBASE%\extrabin

HK> Glad to see that you've found the interfering dll

Or an incorrect search procedure?

e.

19

2017-08-22 23:08 GMT+02:00 Edmund Swylan <Edmund.Swylan@ponymail.com>:

ES> %GISBASE%\bin
ES> C:\WINDOWS\system32
ES> C:\WINDOWS\system
ES> C:\WINDOWS
ES> %APPDATA%\..
ES> %GISBASE%\bin
ES> %GISBASE%\lib
ES> %APPDATA%\GRASS6\addons (In my case this path does not exist.)
ES> %GISBASE%\bin
ES> %GISBASE%\extrabin

HK> Glad to see that you've found the interfering dll

Or an incorrect search procedure?

%GISBASE% paths should be first. Ma

20

On Wed, Aug 23, 2017 at 11:40 AM, Martin Landa <landa.martin@gmail.com> wrote:

2017-08-22 23:08 GMT+02:00 Edmund Swylan <Edmund.Swylan@ponymail.com>:

ES> %GISBASE%\bin
ES> C:\WINDOWS\system32
ES> C:\WINDOWS\system
ES> C:\WINDOWS
ES> %APPDATA%..
ES> %GISBASE%\bin
ES> %GISBASE%\lib
ES> %APPDATA%\GRASS6\addons (In my case this path does not exist.)
ES> %GISBASE%\bin
ES> %GISBASE%\extrabin

HK> Glad to see that you’ve found the interfering dll

Or an incorrect search procedure?

%GISBASE% paths should be first. Ma

IIUC, for MS Windows, this is not possible, system paths always come first.

libtiff.dll is not a native MS Windows dll and should therefore not be in C:\WINDOWS\system32, but local in the directory of the software package that installed libtiff.dll in C:\WINDOWS\system32. This is not a GRASS problem, but an installation error of some other software package.