Due to the varieties of MS-Windows versions existing, a series of problems with the WinGRASS Installation have been identified (and solved):
The GRASS GIS exits when started with g.list CalledModuleError and -1073741511 return code
If GRASS GIS graphical user interface fails to start with error which ends like this:
grass.exceptions.CalledModuleError: Module run None ['g.list', '--q', '-m', 'type=raster'] ended with error Process ended with non-zero return code -1073741511. See errors in the (error) output.
you can try to run the following command manually from the command line (the "black" system command line which was started with GRASS GIS).
g.list -m type=raster
If you run the command, you might get the following error:
The procedure entry point sqlite3_vfs_register could not be located in the dynamic link library sqlite3.dll.
The issue is caused by different sqlite3.dll files accessible "on path" to all application. In case of GRASS GIS, some incompatible sqlite3 DLL is picked up by the system rather than using the correct one shipped with GRASS GIS.
Solution: search for all sqlite3.dll files on your computer and
remove rename them one by one while trying at the same time to start GRASS GIS successfully. Note that removing some of the other sqlite3.dll files may break the applications which use them (say, while this is possible it has never actually been reported by any user). So, it is a good idea to just rename the DLL file in case you discover that another application needs that particular sqlite3 DLL and you have to reverse the process.
Legend and scale bar do not show any text
If you add legend (d.legend) or scale bar (d.barscale) to the Map Display and you see only the colors or the bar but no text:
1. Try to run this command within a GRASS session:
Redraw, the text should appear.
2. Alternatively, in the menu go to Settings > Preferences, then select Map Display tab. Use Set font button to set Default font for GRASS displays. From the list choose arial or another font you wish to use.
The GRASS GIS (winGRASS) exits immediately after I start it complaining about MSVCR DLL
Problem: WinGRASS complains about a missing MSVCR71.dll, MSCVP100.dll or similar on startup or exits immediately.
First note that GRASS GIS 6.4.3 and later 'suggest to install the needed "Important Microsoft runtime libraries" already during the installation process (on the same install wizard page offering to download sample datasets), so you should make sure that you check this option during installation. If you are sure about that or the step ended with error (e.g. when proxy settings were not recognized), follow the instructions below.
You may need to install Microsoft's .NET Framework. You can download it here.
If it still asks for MSVCP100.dll, download it here.
If the above Solution A does not help, or ends with an error, or if it says that you already have everything, you can reproduce steps which the installer is doing:
- You do not need to uninstall GRASS GIS to fix it. But be sure to close any GRASS windows you have still open.
- Download msvcrt-1.0.1-12.tar.bz2 archive
- Uncompress the archive. Note that it is tar.bz2, so to uncompress it use 7-Zip or Winzip or something else that can handle it. It will unzip 3 folders. Keep those 3 folders together (it doesn't matter where).
- Open the "bin" folder (it is in one of the 3 folders from above) and run the following programs (just double click on them) in the indicated order, following the directions in each wizard:
- vcredist_2005_x86.exe (first screen might be in German, just click left button ("Ja"); then it switches to English)
- Once you installed each of these programs, copy the following files (they are in the same "bin" folder) to the "extrabin" folder in the GRASS GIS installation directory (the one you chose during the installation):
- msvcp60.dll, msvcp70.dll, msvcp71.dll, msvcr71.dll, msvcrt.dll
So: paste them into e.g. C:\Program Files (x86)\GRASS GIS 7.0.0beta3\extrabin\ (assuming you used the default install location).
- msvcp60.dll, msvcp70.dll, msvcp71.dll, msvcr71.dll, msvcrt.dll
- Try GRASS GIS again! It should be running now. If not make sure that you have tried all the steps and try again. If this still does not help, please write to the grass-user mailing list.
Error message "ImportError: cannot import name MAXREPEAT"
A system-wide Python installation (2.7.2, independent of GRASS) may cause the trouble. Replacing this system-wide Python installation with version 2.7.4 (or newer 2.7.x), instead of 2.7.2, solves the problem.
A variant of the problem is also seen with "import re" appearing in the error message. The solution is the same: upgrade the system-wide installed version.
Note that you can also try to remove the system-wide installation but this has a higher risk of breaking some (part) other applciation which depends on the system-wide Python.
You have likely an old "libexpat.dll" in your directory %WINDIR%\system32 (or %WINDIR%\sysWOW64). Try to rename that file (or delete after backup). Then winGRASS should work.
You have likely an old "proj.dll" in your directory %WINDIR%\system32 (or %WINDIR%\sysWOW64). Try to rename that file (or delete after backup). Then winGRASS should work.
The winGRASS user interface shows up in the wrong language for me!
MSys users should be setting the LANG, LC_MESSAGES etc. variables in ~/.bash_profile (etc) if they want it set to a specific locale other than the default locale of the system.
This and that is not functioning in my winGRASS installation!
Error message "This application has failed to start because libintl3.dll was not found". (or libiconv2.dll and/or regex2.dll)
Reinstalling of the "msys" package in the OSGeo4W installer will bring it back.
Error message "libfreetype-6.dll not installed" (similar wording)
You may need to install "libfreetype-6.dll" on your system. For this, launch the OSGeo4W Network Installer > Advanced Install, type freetype in the search box and do the freetype packages installation.
The startup fails with a GISDBASE not defined error
Maybe there is junk in the GRASS session configuration file. To see if this is true and to remove the issue. Rename configuration and a new one will be created next time you run GRASS GIS. Follow these steps:
- Find where %APPDATA% directory is; usually it is C:\Users\<username>\AppData.
- Note that %APPDATA% is a hidden folder
- Find the GRASS session configuration file.
- %APPDATA%\GRASS6\grassrc6 for GRASS GIS 6
- %APPDATA%\GRASS7\rc for GRASS GIS 7
- Rename session configuration file, e.g. to grassrc6.old or rc.old
- Now restart GRASS GIS and the error should be gone (if it was caused by bad configuration file).
The startup fails with a IOerror: [Errno 2] No such file or directory : 'nul'
Q: At startup, I get
nul=open <os.devnull, 'w'> IOerror: [Errno 2] No such file or directory : 'nul'
A: Apparently, it's possible for the service implementing the null device ('nul' pseudo-file) to be stopped or to malfunction.
The status can be checked via the control panel. Start the Device Manager (Control Panel > Hardware and Sound > Device Manager), select View > Show hidden devices, then under Non-Plug and Play Drivers, there should be an entry for "Null".
The corresponding registry key is
The Start and Type values should both be 1.
ERROR: G_realloc: unable to allocate xxx bytes of memory at ...
Q: When processing a large dataset, I get something like
Current region rows: rrrrr, cols: ccccc ERROR: G_realloc: unable to allocate XXX bytes of memory at ...
A: In general GRASS GIS 7 is able to manage huge datasets in the multi-GB size. For hints, see Large raster data processing
Error message "Process ended with non-zero return code -1073741571"
This error message may indicate that the Computational region region is containing too many pixels.
Background: according to StackOverflow this number "is the signed integer representation of Microsoft's 'stack overflow/stack exhaustion' error code 0xC00000FD."
The mount of "cells" main exceed that being manageable by your computer: in case if this error message the number of rows/columns is likely too high. Either reduce the extent or lower the resolution.
startup of winGRASS and wxGUI very slow/freezed
Q: The startup, location wizzard and wxGUI of winGRASS is very slow, how come?
A: Some firewall/anti-virus software may be very restrictive regarding new winGRASS version; just update the rules of the firewall/anti-virus software; as all winGRASS release packages are tested for malicious code/virus, they are considered to be secure when originating from the GRASS GIS Web site hosted at OSGeo.
GRASS GIS installation (OSGeo4W or standalone) fails with a sqlite3 error
If the installation fails with an error that an entry point in the sqlite3 dll can't be found, then it is very likely that there is another SQLite library in %PATH% on that windows machine.
First steps are:
- typing in a windows console: where "$path:sqlite3*"
- search in C:\Windows in the explorer for sqlite3*
Windows operating systems don't install natively a SQLite dll in any directory available in %PATH%.
If one of results of the steps above are positive, another software installed the dll in a directory available in %PATH%.
For a successful installation, following steps should be done:
- rename the found dll (e.g. in C:\Windows\System32\sqlite3.dll) to something like xxxsqlite3.dll
- check if installation of winGRASS (OSGeo4W or standalone) works
- if it works, then the software which installed the dll in %PATH% will be broken
- start other installed software on that machine step by step and see which one is now broken
- if the broken software is found, move xxxsqlite3.dll to the installation directory of that software (e.g. e.g. c:\Programs\YourSoftwareBreakingGrass) and rename it back to sqlite3.dll
searching for dependency library issues with dependency walker
- Download dependency walker for your system
- add following lines to the winGRASS startup script, e.g. C:\OSGeo4W64\bin\grass78.bat
rem rem Set environmental variables rem call "%~dp0\o4w_env.bat" call py3_env.bat call "%OSGEO4W_ROOT%\apps\grass\grass78\etc\env.bat" @echo off rem do a dependency walk rem add these lines for %%d in (%GISBASE%\lib\*) do depends /c /f:1 /ot:%APPDATA%\GRASS7\depwalk_lib.log %%d for %%e in (%GISBASE%\bin\*) do depends /c /f:1 /ot:%APPDATA%\GRASS7\depwalk_bin.log %%e rem rem Launch GRASS GIS rem "%GRASS_PYTHON%" "%GISBASE%\etc\grass78.py" %*
- start OSGeo4W winGRASS session and wait some minutes while dependenxy walker is working
- go to the windows folder %APPDATA%\GRASS7\, e.g. C:\Users\YourUsername\AppData\Roaming\GRASS7
- check the 2 log files with a text editor for the library name causing issues, e.g. for gdal300.dll