You might not be able to uninstall Avast! Free Antivirus due to errors during un-installation.
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
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 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..
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
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.
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
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'
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
With this knowledge, this error can be fixed and the solution can be compiled like this:
- Ignore the library dependencies that are indicated by CGAL. This can be done by going to Properties → Linker → Input → Ignore Specific Library and adding
- Link with the available libraries instead. This can be done by going to Properties → Linker → Input → Additional Dependencies and adding
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
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).
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
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:
foo.dvi -> foo.pdf
** 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]
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
I got an error while building CUDPP 1.1.1 with CUDA 3.2. The linker error occurs on building
LINK : fatal error LNK1181: cannot open input file 'cudart.lib'
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
In the CUDPP solution, Change the Additional library dependencies in the Visual Studio solution from
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.
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
Tried with: CUDA 3.2 and Visual Studio 2008
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:
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
lock file in the
.hg\store directory of the repository. In the example above, delete the file
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.
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.