Tag Archives: errors

Avast! Free Antivirus: Uninstall Problems

by

Problem

You might not be able to uninstall Avast! Free Antivirus due to errors during un-installation.

Solution

One easy way to fix this is to choose to Change in the Uninstall dialog. Avast will try to update and re-install itself from the Internet when this option is chosen. Un-installation after this should work.

Tried with: Avast! Free Antivirus 5.1.889

CUDA: Exception due to GPU Architecture Mismatch

by

Symptom

Your CUDA program executes, but the computed result is wrong. You run the program in Debug mode and it spews out a bunch of first-chance exceptions on cudaError_enum and cudaError of this form in the Output window:

First-chance exception at 0x74dcb727 in HelloCUDA.exe: Microsoft C++ exception: cudaError_enum at memory location 0x002af650..
First-chance exception at 0x74dcb727 in HelloCUDA.exe: Microsoft C++ exception: cudaError at memory location 0x002af4ec..
First-chance exception at 0x74dcb727 in HelloCUDA.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000..

Diagnosis

One of the reasons for this behaviour is if the device you are using cannot support the compute capability the program was compiled for. Ideally, such a program should be able to detect the device capability, compare and exit with a meaningful error. I have no idea why NVIDIA does not do this.

Anyway, if your device is of compute capability 1.1 and the program was compiled for compute capability 2.0, that is sm_20 GPU architecture, then it can result in such silent failures. Recompile the program for the compute capability of your device and the error should be gone.

Tried with: CUDA 4.0

CUDA: Initialization Error

by

Problem

Your CUDA program is failing without giving any clue. You check the error value returned by CUDA runtime calls. You discover that one of the first few CUDA runtime calls, probably a cudaMalloc, is failing with an Initialization error. There is no initialization required to start calling CUDA APIs or kernels, so you now wonder what is this error and how to fix it.

Solution

NVIDIA could have been more informative with their error messages. The initialization error usually indicates that something went bad when the CUDA runtime communicated with the CUDA driver. One of the popular causes of this error is if the driver is older than the CUDA toolkit. Each release of CUDA toolkit ships with a driver. Note the version of this driver. Only drivers of the same or later version numbers will work well with that CUDA toolkit. Install the latest driver and this error should go away.

Tried with: CUDA 4.0

CGAL: GMP and MPFR Linker Errors

by

Problem

Compiling any Visual C++ solution that uses CGAL produces either or both of these errors:

1>LINK : fatal error LNK1104: cannot open file 'gmp-vc90-mt.lib'
1>LINK : fatal error LNK1104: cannot open file 'mpfr-vc90-mt.lib'

Solution

CGAL seems to look for GMP and MPFR libraries, whose names are suffixed with the Visual C++ version (vc90) and the build type (mt). However, CGAL stopped shipping pre-built GMP and MPFR libraries in such a format a while ago. Instead it ships a single library file for each. For example, in CGAL 3.8, these files are libgmp-10.lib and libmpfr-4.lib.

With this knowledge, this error can be fixed and the solution can be compiled like this:

  1. Ignore the library dependencies that are indicated by CGAL. This can be done by going to Properties → Linker → Input → Ignore Specific Library and adding gmp-vc90-mt.lib,mpfr-vc90-mt.lib
  2. Link with the available libraries instead. This can be done by going to Properties → Linker → Input → Additional Dependencies and adding libgmp-10.lib libmpfr-4.lib

The Visual C++ solution using CGAL should be able to build and execute without errors now.

Tried with: Visual C++ 2008 and CGAL 3.8

EPS: Bounding Box Problem

by

Problem

Some EPS file generators produce a BoundingBox attribute that is all zeroes. This can fail certain programs that depend on non-zero BoundingBox values in EPS files. (For an example of such a failure see here).

Solution

Here is a quick hack that might work. EPS files are text files and can be opened and edited using any text editor. Open the EPS file in a text editor and check if it has a HiResBoundingBox attribute. If it does, you are in luck! :-) Copy over its values to the BoundingBox attribute. If this does not work, copy over the HiResBoundingBox values and convert them to integers for BoundingBox.

DVIPDFM: Transformation Matrix Error

by

Problem

The dvipdfm program is used to convert a DVI file to a PDF file. For a DVI file which has EPS image files inside, this conversion might sometimes fail with the error shown below:

C:\Users\joe>dvipdfm foo.dvi
foo.dvi -> foo.pdf
[1
** WARNING ** Image width=0.0!
** WARNING ** Image height=0.0!
** WARNING ** Transformation matrix not invertible.
** WARNING ** --- M = [0 0 0 0 233.624 -249.417]
]

Solution

This error indicates that one or more of the EPS image files included in the DVI file have no width and height information. This is typically caused by EPS files whose BoundingBox parameters are all zero. You can check this by opening the EPS file in a text editor and look for a line that resembles this:

%%BoundingBox: 0 0 0 0

If you can generate EPS files that have non-zero bounding box values, this conversion error should be gone. For a quick hack to fix an existing EPS file with these values see here.

Tried with: MiKTeX 2.9

CUDPP: LNK1181 Linker Error

by

Problem

I got an error while building CUDPP 1.1.1 with CUDA 3.2. The linker error occurs on building cudpp_vc90.sln:

LINK : fatal error LNK1181: cannot open input file 'cudart.lib'

Reason

NVIDIA is notorious for frequently changing their environment variables and their paths. I have commented on this before here and here. They have done it again with CUDA 3.2! :-| cudpp_vc90.vcproj looks for cudart.lib in the directory $(CUDA_LIB_PATH)/../lib. CUDA 3.2 has moved these files to $(CUDA_LIB_PATH).

Solution

In the CUDPP solution, Change the Additional library dependencies in the Visual Studio solution from $(CUDA_LIB_PATH)/../lib to $(CUDA_LIB_PATH).

Note

I have reported this error to CUDPP here. A committer has merged the fix. But, given the fact that the last release was a year ago, it might be a while before this fix appears in a stable release.

Tried with: CUDPP 1.1.1, CUDA 3.2, Visual Studio 2008 and Windows 7 64-bit.

CUDA: LNK2005 Linker Errors

by

The Problem

When building a Visual Studio solution which has CUDA source files (*.cu), LNK2005 linker errors of the following kind might be seen:

LIBCMT.lib(hooks.obj) : error LNK2005: "void __cdecl terminate(void)" (?terminate@@YAXXZ) already defined in MSVCRT.lib(MSVCR90.dll)

What does it mean?

This indicates a mismatch between the kind of C runtime library used by the CUDA Build Rule and that used for the rest of the Visual C++ project.

How to fix it?

This problem can be fixed by making both of these use the same kind of C runtime library. For example, if the Visual C++ project is compiled using Multi Threaded DLL (/MD) and the CUDA build rule has Multi Threaded (/MT), then change the CUDA build rule to use /MD too.

 

Tried with: CUDA 3.2 and Visual Studio 2008

Mercurial: Waiting for Lock

by

Problem

Mercurial repositories can sometimes be left in a locked state. A lock is created whenever a client is connected to a repository. But, this lock is not removed if the client got disconnected, say over the network. If any client now tries to change the repository (say push changes), Mercurial complains that it is waiting for the lock.

Here is an example:

P:\Foobar>hg push
pushing to Q:\FoobarRep
waiting for lock on repository Q:\FoobarRep held by 'Computer42:9999'

In this example, Mercurial is complaining that a lock is still being held by a client from the computer named Computer42 over port 9999.

Solution

Delete the lock file in the .hg\store directory of the repository. In the example above, delete the file Q:\FoobarRep\.hg\store\lock

Windows 7: Explorer Problems

by

Problem

The Explorer process in Windows 7 handles the taskbar and any of the Explorer instances you create to browse directories. Due to file handles problems with applications, directories on plugged-in portable devices or on network share folders, Explorer might sometimes behave erratically. You might face one of these problems with Explorer:

  • Explorer hangs while displaying a directory or during a cut-copy-paste operation.
  • Explorer does not show up when its invoked by clicking its icon or by pressing the keyboard shortcut Win + e.
  • Taskbar is frozen or has disappeared.

Solution

First, it is better to carefully kill all currently running Explorer instances. To do this open Task Manager. One way to do this is using the keyboard shortcut Ctrl + Shift + Esc. In Task Manager, click the Processes tab, there should be one or more explorer.exe instances. Right-click on each explorer.exe and choose End Process. Do not choose End Process Tree! That would kill explorer.exe and all the application processes it might have spawned, this is not good. End Process only kills explorer.exe, making its children processes as orphans, but they are otherwise unharmed. All open Explorer windows and the Taskbar disappear after this operation.

Next, create a fresh new instance of Explorer. This can be done in Task Manager itself. Switch to the Applications tab and click New Task. Type in explorer and click OK. Your taskbar should be back and hopefully you should be able to invoke Explorer without any problems after this.