More

Fixing Script Error Invalid Pointer from ArcGIS Geoprocessing Tools?


I am just learning ArcGIS 10.2 and it was working well until I tried to use the Export to a Geodatabase (single) option for a dbs table I made. Since then, it seems I now get the same Script Error for import/export functions. However, I just tried to export to Geodatabase (multiple) and error did not pop up. I spoke with tech support and they could not help me so far. I really do not know much about GIS so it is hard for me to fix this problem and cannot proceed with some things.


I just solved this problem. What you need to do is the following: In Windows go to: Control Panel -> Programs -> Uninstall a program.

Then right click on "ArcGIS for Desktop" -> Select "Uninstall/change".

The ArcGIS Setup dialog will pop up. Chose the "Repair" option.

After finishing the Repair procedures the ArcGIS will be working properly!


I resolved this error by repairing the data interop. installation. I also have background processing turned off.


2 Answers 2

Best to backup partition table first, just in case changes are not correct. Then it is possible to restore old partition table. If drive is sda & save to another drive:

Use gdisk and verify partitions are correct with p , and use w to write the partition table. If not correct just use q to quit. That should update primary, backup & protective MBR.

b back up GPT data to a file
c change a partition's name
d delete a partition
i show detailed information on a partition
l list known partition types
n add a new partition
o create a new empty GUID partition table (GPT)
p print the partition table
q quit without saving changes
r recovery and transformation options (experts only)
s sort partitions
t change a partition's type code
v verify disk
w write table to disk and exit
x extra functionality (experts only)
? print this menu

Be sure to see comment below by Rod Smith, he is author of gdisk at his rodbooks site.


Fixing Windows Devices That Can't Start

When a system has problems starting, it might display error messages at startup. These messages might come from the system BIOS (ROM BIOS or UEFI firmware) or might be generated by Windows. Typical error messages displayed by the BIOS include the following:

  • Invalid system disk
  • Boot failure
  • Hard disk error
  • NT boot loader missing
  • Missing operating system

These and similar messages indicate that the BIOS or UEFI firmware chip on the motherboard cannot locate startup files for your operating system. Possible reasons can include the following:

  • A nonbootable drive containing media is listed first in the boot order (BIOS/UEFI).
  • The computer’s system drive is not properly identified (BIOS/UEFI).
  • Data or power cables from the internal hard disk to the motherboard are loose or have failed (hardware).
  • The drive has failed (hardware).

These are listed in order of likelihood. As always, start with the simplest possibility: You’ve left a USB thumb drive plugged into your computer.

Disconnecting USB Drives

If your system is configured to use USB drives as the first bootable device and you leave a nonbootable USB flash drive plugged into your system (either directly or into a USB hub connected to your system), your system won’t boot. Solution? Unplug the drive and restart your system.

If your system restarts correctly, you have a couple of choices:

  • Don’t leave USB flash drives plugged into your system when you shut down the computer.
  • Change your BIOS or UEFI firmware settings to skip USB drives as bootable devices.

Checking and Changing Drive Boot Order

Should you change the boot order? It depends. More and more diagnostic programs can be run from bootable USB flash drives, and you can also install new operating systems from bootable USB flash drives. However, you can also use your system’s DVD or BD (Blu-ray) drive for these tasks. So, it’s up to you.

We recommend changing the boot order on Windows 7 computers if

  • You use USB flash drives to speed up your system using the Windows ReadyBoost feature.
  • You frequently use USB flash drives to shuttle information between computers.
  • You frequently use USB flash drives for other reasons.

However, you should leave USB flash drives at the top of the boot order if

  • You frequently run diagnostic programs from a bootable USB flash drive.
  • You install operating systems from a bootable USB flash drive.
  • You seldom or never use USB flash drives for data transfer.

If you change the boot order to remove USB flash drives or put them after the system hard disk, you can always change the boot order in the future to place USB drives first if you need to run diagnostic programs or install a new operating system.

Here’s how to change the boot order in Windows 7:

  1. Click Start.
  2. Click the right arrow next to the Shut Down button.
  3. Select Restart.

After your system restarts, press the key that starts the BIOS or UEFI firmware setup program (see Figure 8.3).

Figure 8.3 On some systems, such as this HP Pavilion DV6 laptop, you might need to press a key (ESC) to see startup options including BIOS setup (F10).

Navigate to the dialog used to set the drive boot order (see Figure 8.4).

Figure 8.4 This system looks for USB thumb drives as the first bootable devices.

Windows 8.1 (unlike Windows 8) does not support the creation of a CD or DVD repair disc, although you can use your Windows 8.1 distribution media as a repair disc. With Windows 8.1, if your system supports booting from a USB drive, you should create a USB recovery drive instead.

STOP (Blue Screen) Errors at Startup

If you turn on your Windows computer and, instead of seeing the Windows login screen or desktop, you see a screen similar to the one shown in Figure 8.5, you have a STOP error, also known as a “Blue Screen” or BSOD (“blue screen of death) error. What happened?

Figure 8.5 A 0x7B STOP error in Windows 7 caused by changing the SATA interface setting in the system BIOS (a). Windows 8 displays a different STOP error (b).

Blue-screen errors can be caused by many problems. At startup, they’re typically caused by problems with hard disk device drivers. If a blue screen error appears after you have booted to the Windows desktop, it could be caused by corrupt apps, corrupt device drivers, or memory problems.

When you see a BSOD error, be sure to record the numbers listed after the STOP message, such as STOP: 0x0000001E, or 0x1E for short. If the name of the error is displayed, such as KMODE_EXCEPTION_NOT_HANDLED, record it as well. You can then look up the error number and name on the Microsoft Support Site (http://support.microsoft.com) to find Microsoft’s suggested solutions.

Table 8.2 lists some of the most common STOP errors and possible solutions.

Table 8.2 Common Windows STOP Errors and Solutions

STOP Error Number

STOP Error Name

Suggested Solutions

Check device drivers or services used by backup or antivirus utilities.

Check device drivers or services used by backup or antivirus utilities.

Illegal or unknown instruction check the driver referenced in the error message.

Test the hard disk for errors.

Test memory modules disable memory caching in system BIOS check hardware configuration.

Incorrect or missing hard disk device driver see “Fixing 0x7B Errors,” this chapter, for details.

Test hardware and RAM check SCSI configuration if in use make sure CPU is not overclocked.

Check power management and CD-writing software disable power management temporarily reinstall or upgrade CD-writing software.

Reinstall third-party programs use System File Checker with the Scannow option (SFC/Scannow) to check system files.

Unfortunately, Windows is typically configured to restart the system immediately when a STOP error is displayed, so you can’t read it. To configure Windows so that a STOP error stays onscreen so you can determine what it is and look for solutions, see “Preparing a Windows-Based Computer or Tablet for Easier Troubleshooting,” Chapter 1, p.37.

You can also disable rebooting in case of a STOP error with the startup option to Disable Automatic Restart After Failure or Disable Automatic Restart on System Failure. See “Disable Automatic Restart on System Failure,” this chapter, p.222.

Fixing 0x7B Errors at Startup

If you are building a computer, have just upgraded to a new hard disk, or have just replaced the motherboard battery that maintains system settings, it’s possible that your computer has “forgotten” the correct hard disk configuration settings.

Almost all hard disks are configured using Auto as the hard disk type. Thus, if the setup information is lost, the default (normal) setting is Auto and the drive will be properly detected.

However, the setting for the SATA interface used by your hard disk can be a problem. There are several possible settings for the SATA interface (IDE, AHCI, and RAID), and if your system is configured using one setting, but a different setting is used in the system BIOS or UEFI firmware, your computer won’t start, displaying a 0x7B STOP error (refer to Figure 8.5).

If you know the correct setting, follow these steps:

  1. Shut down the computer and restart it.
  2. Start the BIOS or UEFI firmware setup program.
  3. Change the SATA setting to the correct value.
  4. Save settings and restart the computer.
  5. Select Start Windows Normally if prompted.

If you don’t know the correct setting to use in step 3, choose IDE (also known as ATA or Compatible) if the system is set to AHCI, or AHCI if the system is set to IDE, ATA, or Compatible.

Switching to AHCI Mode in Windows 7 and Windows 8.x

If your SATA drives are currently set to run in IDE mode, but you are planning to install an SSD, keep in mind that an SSD cannot provide you with faster performance unless you use AHCI mode. If the system crashes when you change SATA modes, how can you safely change from IDE to AHCI mode?

AHCI mode is also recommended for full performance with SATA 3Gbps and 6Gbps hard disk drives.

Before you make the switch, you need to enable Windows to use AHCI drivers when necessary.

The easiest way for Windows Vista and Windows 7 is to use the Fix-It wizard available from http://support.microsoft.com/kb/922976. This page also details manual Registry changes that make the same changes as the Fix-It Wizard.

After you run the Fix-It Wizard or make the needed changes manually, you can safely enable AHCI mode in the system BIOS or UEFI firmware setup dialog (refer to Figure 8.8), and your system will install the appropriate drivers and run properly.

To switch from IDE mode to AHCI mode in Windows 8.x, follow this procedure (adapted from http://superuser.com/questions/471102/change-from-ide-to-ahci-after-installing-windows-8):

Click the empty Safe Boot box (see Figure 8.6).

Figure 8.6 Make sure Safe Boot is checked before you click OK.

Click or tap Restart Now (see Figure 8.7).

Figure 8.7 Restart Now enables you to change firmware (BIOS/UEFI) settings.

Change the SATA mode to AHCI (see Figure 8.8).

Figure 8.8 Preparing to change a system configured for IDE mode to AHCI mode.

Your computer will restart using AHCI mode for full performance of your SATA devices.

Loose Drive Data and Power Cables

The interior of a desktop PC is a cluttered place. Whether you had your system opened up for a memory upgrade, component replacement, or just to see what’s “under the hood,” you might have loosened or disconnected the power or data cables going to the hard disk or the data cable connecting the hard disk to the motherboard. If your system (C:) drive has disconnected or loose cables, you will see No Operating System or other similar error messages.

Most SATA data cables do not lock into place, so it’s easy to have a loose cable on either a drive (see Figure 8.9) or the motherboard (see Figures 8.10 and 8.11).

Figure 8.9 Loose data cable on an SATA hard disk.

Figure 8.10 An SATA motherboard host adapter with a loose data cable.

Figure 8.11 Some motherboards use front-mounted SATA ports, like this one, which also features a loose data cable.

Similarly, SATA power cables can come loose from drives (see Figure 8.12).

Figure 8.12 The power cable on this SATA drive is not connected tightly.

To solve problems with loose or disconnected cables:

  1. Shut down the computer.
  2. Disconnect the power supply from AC power.
  3. Open the system.
  4. Check the hard disk or SSD for loose or disconnected cable(s).
  5. Check the motherboard for loose or disconnected SATA data cables.

Securely plug the cable(s) into place (see Figures 8.13, 8.14, and 8.15).

Figure 8.13 An SATA hard disk with properly connected power and data cables.

Figure 8.14 A correctly installed SATA data cable plugged into a top-facing motherboard port.

Figure 8.15 A correctly installed SATA data cable plugged into a front-facing motherboard port.

Drive Failure

If your hard disk is making a loud or rattling noise when it’s running, it has probably failed. If the hard disk was dropped or smacked hard, a failure is very likely.

However, a hard disk might have failed if it is absolutely silent even when you place your ear next to it or does not get warm after the system has been on for several minutes.

Before assuming a hard disk has failed, perform this isolation test to determine whether the problem is the hard disk, its power cable, or its data cable:

  1. Shut down the computer.
  2. Disconnect the power supply from AC power.
  3. Open the system.
  4. Locate the power cable running between the hard disk and the power supply.
  5. Disconnect the power cable from the power supply.
  6. If the power cable used a splitter or converter to provide power to the drive, plug the drive directly into the power supply (if possible). If that is not possible, replace the splitter or converter and make sure it is securely plugged into the power supply lead and the drive.
  7. Reconnect the power supply to AC power.
  8. Restart the computer.
  9. If the drive is still not working, repeat steps 1 and 2.
  10. Reconnect the drive to the original power cable (and splitter or converter).
  11. Remove the data cable from the hard disk drive and the computer.
  12. Install a known-working replacement cable.
  13. Plug it into the SATA port on the motherboard and drive.
  14. Repeat steps 7 and 8.
  15. If the drive is still not working, the drive has failed. Replace it.

If you have backed up your information, you can replace your hard disk and restore your system from a backup. However, if you have no backup and the information is vital, you can use a data recovery company to recover your data. These companies have clean rooms that enable safe replacement of failed components and advanced data-extraction techniques. Expect to pay hundreds of dollars for recovery – if the drive’s condition permits it.


I just ran into this same problem and tracked down the root cause: the C_INCLUDE_PATH environment variable. Mine happened to be set as follows:

This came from a login script somewhere that was doing something like

while setting up my environment. That looks correct at first glance unfortunately, it seems to be the case that foo: is equivalent to foo:. in this context-- that is, the empty string in that two-item colon-separated list seems to be implicitly treated the same as . . Which effectively adds the current directory to the system include path, which makes #include <poll.h> do the same thing as #include "poll.h" , which is bad.

In Perl's case, the rogue include path causes Perl's poll.h to include itself instead of /usr/include/poll.h . Since Perl's poll.h has a guard against multiple inclusion, the second include silently does nothing, and you end up with no poll.h at all, which quickly leads to the compiler error we both saw. This also explains why your patch makes the problem go away: there is no ./sys/poll.h in the build directory, so the compiler ends up finding /usr/include/sys/poll.h , which ultimately happens to be what you wanted.

My solution was to get rid of the stray colon in C_INCLUDE_PATH . In my case, I found the script that was setting it incorrectly and fixed it so that it explicitly checks for the case where the previous C_INCLUDE_PATH was empty, and not add a colon in that case. Of course, as a quick one-off fix, I could also have manually run export C_INCLUDE_PATH=/home/me/REDACTED/include or just unset C_INCLUDE_PATH before building Perl.


() runs commands in the subshell, so by exit you are exiting from subshell and returning to the parent shell. Use braces <> if you want to run commands in the current shell.

(list) list is executed in a subshell environment. Variable assignments and builtin commands that affect the shell's environment do not remain in effect after the command completes. The return status is the exit status of list.

list is simply executed in the current shell environment. list must be terminated with a newline or semicolon. This is known as a group command. The return status is the exit status of list. Note that unlike the metacharacters ( and ), < and >are reserved words and must occur where a reserved word is permitted to be recognized. Since they do not cause a word break, they must be separated from list by whitespace or another shell metacharacter.

It's worth mentioning that the shell syntax is quite consistent and the subshell participates also in the other () constructs like command substitution (also with the old-style `..` syntax) or process substitution, so the following won't exit from the current shell either:

While it may be obvious that subshells are involved when commands are placed explicitly inside () , the less visible fact is that they are also spawned in these other structures:

command started in the background

doesn't exit the current shell because (after man bash )

If a command is terminated by the control operator &, the shell executes the command in the background in a subshell. The shell does not wait for the command to finish, and the return status is 0.

still exits only from the subshell.

However different shells behave differently in this regard. For example bash puts all components of the pipeline into separate subshells (unless you use the lastpipe option in invocations where job control is not enabled), but AT&T ksh and zsh run the last part inside the current shell (both behaviours are allowed by POSIX). Thus

does basically nothing in bash, but exits from the zsh because of the last exit .

coproc exit also runs exit in a subshell.

Executing the exit in a subshell is one pitfall:

The script prints 42, exits from the subshell with return code 1 , and continues with the script. Even replacing the call by echo $(CALC) || exit 1 does not help because the return code of echo is 0 regardless of the return code of calc . And calc is executed prior to echo .

Even more puzzling is thwarting the effect of exit by wrapping it into local builtin like in the following script. I stumbled over the problem when I wrote a function to verify an input value. Example:

I want to create a file named "year month day.log", i.e., 20141211.log for today. The date is input by a user who may fail to provide a reasonable value. Therefore, in my function fname I check the return value of date to verify the validity of the user input:

Looks good. Let the script be named s.sh . If the user calls the script with ./s.sh "Thu Dec 11 20:45:49 CET 2014" , the file 20141211.log is created. If, however, the user types ./s.sh "Thu hec 11 20:45:49 CET 2014" , then the script outputs:

The line fname… says that the bad input data has been detected in the subshell. But the exit 1 at the end of the local … line is never triggered because the local directive always return 0 . This is because local is executed after $(fname) and thus overwrites its return code. And because of that, the script continues and invokes touch with an empty parameter. This example is simple but the behavior of bash can be quite confusing in a real application. I know, real programmers don't use locals.☺

To make it clear: Without the local , the script aborts as expected when an invalid date is entered.

The fix is to split the line like

The strange behavior conforms to the documentation of local within the man page of bash: "The return status is 0 unless local is used outside a function, an invalid name is supplied, or name is a readonly variable."

Though not being a bug I feel that the behaviour of bash is counterintuitive. I am aware of the sequence of execution, local should not mask a broken assignment, nevertheless.

My initial answer contained some inaccurancies. After a revealing and in-depth discussion with mikeserv (thank you for that) I went for fixing them.


I don't know what is producing the gigabytes of error in syslog

I think the error is caused by VLC. Try using another Media Player.

/.local/share/sddm/xorg-session.log -> 77G -> vdpau_chroma filter error: video mixer features failure: An invalid handle value was provided. -> VLC + nvidia drivers causes this. &ndash karpi Jan 13 '20 at 11:20

There is a bug filed for this large /var/log/syslog at Having a video playing/paused when switched to another user generates gigabytes of error logs. In the bug description, it is mentioned that using a video player (e.g., VLC) is a way to pop the error. It is not clear if VLC is the only player that produces the error.

The bug was not solved. But as a way to stop the output, closing VLC apparently works. As per messages in the bug thread, and my own experience, avoiding having a playing video while switching users, and perhaps workspaces, should prevent the issue from appearing. The answer by nyxee is a related workaround.

"Paul_Pedant, I have googled but was not able to find anything useful".

I googled "org.gnome.Nautilus[1514]: [00007fa4fc465ce0] vdpau_chroma filter error: video mixer features failure: An invalid handle value was provided" and up popped four helpful posts.

Two of them concern syslog messages about "invalid handle value", and other two about "AssertionMessage: *** Error in `nautilus': free(): invalid pointer: 0x0993d258 ***". Those are probably the same root cause, because a pointer to free() is just a handle too. If Nautilus is corrupting its own memory, no telling what junk comes out.

Having a video playing/paused when switched to another user generates gigabytes of error logs. syslog messages about "invalid handle value"

nautilus assert failure: *** Error in `nautilus': free(): invalid pointer: 0x00007fc7ec3a8800 ***

nautilus assert failure: *** Error in `nautilus': free(): invalid pointer: 0x0993d258 ***

Disabling nvidia driver logging errors

Maybe you should answer my detailed questions, or just uninstall and reinstall Nautilus, or check your versions against these bug reports, or file a bug on one of these sites. I don't have pop-os or Nautilus or Ubuntu or nvidia or a problem, so I can't investigate this further.


Unable to launch the IIS Express Web server error on Visual Studio 2015 – How to fix it

Working with Visual Studio on recent Windows versions such as Windows 10 can be tricky, as the improved security settings of the new OS might create some issues on a developer machine, which often need to have access to some system files – expecially when working with IIS Express. We talked about that in a number of post, for example here (error accessing IIS Metabase), here (allow external requests from remote machines) and also here (Process with an ID #### error).

Here we’ll introduce another issue you might stumble upon while working with an ASP.NET Core or MVC solution, right after you try to execute it in debug mode:

Unable to launch the IIS Express Web server

There are many workaround that might fix this issue: we suggest to try them one after another, stopping only when you manage to fix it.

  1. Delete the DocumentsIISExpress folder using the following console command: rmdir / s / q "%userprofile%DocumentsIISExpress"
  2. Delete the applicationhost.config file which is placed within the .vsConfig folder in your Visual Studio project root folder.
  3. Close Visual Studio and re-start it with Administrative priviledges (right-click > Run as Administrator).
  4. Change the project’s website random URL: within Visual Studio, right-click to the project node in Solution Explorer, then select Properties navigate through the Web panel, then change the number in the Project Url textbox value.
  5. Add the _CSRUN_DISABLE_WORKAROUNDS Environment System variable with the value of 1 as shown in the following screenshot (thanks to Juan M. Elosegui for reporting this on this SO thread and for the image):

In case you manage to fix the issue, let us know which of the given workarounds worked for you by leaving a feedback in this post’s comment section.

That’s it for now: happy coding!

Related Posts

Review Assistant – Peer code review tool for Visual Studio Introducing Review Assistant, a useful code review plug-in for Visual Studio to create review requests and respond to them from within the UI

December 14, 2019 January 7, 2021

Source Control Switcher – Visual Studio Extension A lightweight Visual Studio Extension that automatically sets the Source Control Provider according to the one used by the current Visual Studio project

October 5, 2019 October 10, 2019

Visual Studio – The components for communicating with FTP servers are not installed Error – How to fix

November 15, 2017 January 7, 2021

About Ryan

IT Project Manager, Web Interface Architect and Lead Developer for many high-traffic web sites & services hosted in Italy and Europe. Since 2010 it's also a lead designer for many App and games for Android, iOS and Windows Phone mobile devices for a number of italian companies. Microsoft MVP for Development Technologies since 2018.

15 Comments on “Unable to launch the IIS Express Web server error on Visual Studio 2015 – How to fix it”

re-started visual studio with Administrative privileges and it worked

The above solution worked perfectly, thanks :)

Thank you so much, All the other threads I found didn’t help. I completed steps 1-4 before trying again. Not sure which one did the trick but I’m up and running.


On a modern Ubuntu system (and many other GNU/Linux distributions), fixing a corrupted sudoers file is actually quite easy, and doesn't require rebooting, using a live CD, or physical access to the machine.

To do this via SSH, log in to the machine and run the command pkexec visudo . If you have physical access to the machine, SSH is unnecessary just open a Terminal window and run that pkexec command.

Assuming you (or some other user) are authorized to run programs as root with PolicyKit, you can enter your password, and then it will run visudo as root , and you can fix your /etc/sudoers .

If you need to edit one of the configuration files in /etc/sudoers.d (which is uncommon in this situation, but possible), use pkexec visudo -f /etc/sudoers.d/filename .

If you have a related situation where you have to perform additional system administration commands as root to fix the problem (also uncommon in this circumstance, but common in others), you can start an interactive root shell with pkexec bash . Generally speaking, any non-graphical command you'd run with sudo can be run with pkexec instead.

(If there is more than one user account on the system authorized to run programs as root with PolicyKit, then for any of those actions, you'll be asked to select which one you want to use, before being asked for your password.)

If that doesn't work--for example, if there are no users authorized to run programs as root via PolicyKit--then boot from an Ubuntu live CD (like the CD you probably used to install Ubuntu) and mount the filesystem for the installed system. You can do this by running sudo parted -l to view your partitions--there is probably just one ext4 partition, and that's the root filesystem.

Suppose the installed Ubuntu system's root filesystem is on /dev/sda1 . Then you could mount it with sudo mount /dev/sda1 /mnt . Then you can edit the installed system's sudoers file with sudo nano -w /mnt/etc/sudoers . Or, even better, you can edit it with

(which will prevent you from saving a sudoers file with incorrect syntax).


6 Answers 6

You've got it right. Be paranoid. Don't trust other code, even if it's your own code. You forget things, you make changes, code evolves. Don't trust outside code.

A good point was made above: what if the inputs are invalid but the program does not crash? Then you get garbage in the database and errors down the line.

When asked for a number (e.g. price in dollars or number of units) I like to enter "1e9" and see what the code does. It can happen.

Four decades ago, getting my B.S. in Computer Science from U.C.Berkeley, we were told that a good program is 50% error handling. Be paranoid.

You already have the right idea

Which of the two approaches to handling wrong input would you advise?

Inconsistent input --> no action + notification

Inconsistent input --> appropriately handled action

You can't really take a cookie cutter approach to programming (you could) but you'd end up with a formulaic design which does things out of habit rather than from conscious choice.

Temper dogmatism with pragmatism.

Steve McConnell said it best

Steve McConnell pretty much wrote the book (Code Complete) on defensive programming and this was one of the methods that he advised that you should always validate your inputs.

I don't recall if Steve mentioned this, however you should consider doing this for non-private methods and functions, and only others where deemed necessary.

There's no "correct" answer here, particularly without specifying the language, the type of code, and the type of product that the code might go into. Consider:

Language matters. In Objective-C, it's often okay to send messages to nil nothing happens, but the program doesn't crash, either. Java doesn't have explicit pointers, so nil pointers aren't a big concern there. In C, you need to be a little more careful.

To be paranoid is to unreasonable, unwarranted suspicion or mistrust. That's probably not any better for software than it is for people.

Your level of concern should be commensurate with the level of risk in the code and the probable difficulty of identifying any problems that do show up. What happens in the worst case? The user restarts the program and continues where they left off? The company loses millions of dollars?

You can't always identify bad input. You can religiously compare your pointers to nil, but that only catches one out of 2^32 possible values, nearly all of which are bad.

There are a lot of different mechanisms for dealing with errors. Again, it depends to some degree on the language. You can use assert macros, conditional statements, unit tests, exception handling, careful design, and other techniques. None of them is foolproof, and none is appropriate for every situation.

So, it mostly boils down to where you want to put responsibility. If you're writing a library for use by others, you probably want to be as careful as you reasonably can about the inputs you get, and do your best to emit helpful errors when possible. In your own private functions and methods, you might use asserts to catch silly mistakes but otherwise put responsibility on the caller (that's you) to not pass garbage in.

There should definitely be a notification, such as a thrown exception. It serves as a heads up to other coders who may be misusing code you wrote (trying to use it for something it wasn't intended to do) that their input is invalid or results in errors. This is very useful in tracking down errors, whereas if you simply return null, their code will continue along until they try to use the result and get an exception from different code.

If your code encounters an error during a call to some other code (perhaps a failed database update) which is beyond the scope of that particular piece of code, you really have no control over it and your only recourse is to throw an exception explaining what you know (only what you are told by the code you've called). If you know that certain inputs will inevitably lead to such a result, you can just not bother executing your code and throw an exception stating which input is not valid and why.

On a more end-user related note, it is best to return something descriptive yet simple so that anyone can understand it. If your client calls and says "the program crashed, fix it", you have a lot of work on your hands tracking down what went wrong and why, and hoping you can reproduce the problem. Using proper handling of exceptions can not only prevent a crash, but provide valuable information. A call from a client saying "The program is giving me an error. It says 'X Y Z is not valid input for method M, because Z is too large", or some such thing, even if they have no idea what it means, you know exactly where to look. Additionally, depending on your/your company's business practices, it might not even be you fixing these problems, so it is best to leave them a good map.