FULL PRODUCT VERSION :
java version "1.7.0-ea"
Java(TM) SE Runtime Environment (build 1.7.0-ea-b113)
Java HotSpot(TM) Client VM (build 20.0-b01, mixed mode, sharing)

FULL OS VERSION :
Windows XP Pro SP3

A DESCRIPTION OF THE PROBLEM :
The JDK 7 virtual machine dynamic link library (jvm.dll) depends statically* on the file msvcr100.dll, but puts it in a location where the operating system image loader can't see it.
This means that most Java applications don't run any more after installing JDK 7.

  To solve this issue, one of the following changes must be made:
1) Put the file msvcr100.dll in the System32 folder. I have tested this and it solves the problem, since the loader looks in this folder when it tries to find a module. (So I'm not reporting this for me, since my problem has gone. Rather, I report this so future users won't have to suffer from this.)
2) Don't link to msvcr100.dll statically,* but link to it dynamically using LoadLibraryW or its kin. In this case it will be necessary to figure out the path to jvm.dll (you can do this because it's possible to obtain the module from the address of any function in it, and in turn the path from the module) and then use that to figure out the correct location of msvcr100.dll and load it from there.

I have in the past seen projects that tried to solve issues like this using the path system variable, but in my experience that causes more problems than it solves, e.g. in the case of conflicts or users with different search paths. It also doesn't seem right to alter a global system variable for this.

* (footnote) Sorry for the confused lingo, but that isn't my doing. In Win32 parlance, if you link statically to a dynamic link library, that means that you statically link to the import library (or perform some equivalent action) making the image loader responsible for loading the library.

THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: Did not try

THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: Did not try

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1) Install Windows XP Pro SP3 on an otherwise clean computer.
2) Install JDK 7.
3) Try to run any Java application that tries to spawn a virtual machine by loading the jvm.dll module.

EXPECTED VERSUS ACTUAL BEHAVIOR :
Expected: running application.
Actual results: an error message from csrss complaining about the missing DLL and then possibly another message from the application complaining that the virtual machine can't be started, depending on the application.
ERROR MESSAGES/STACK TRACES THAT OCCUR :
(Roughly translated into English:)
The application cannot be started because the file MSVCR100.DLL cannot be found. Reinstalling the application might fix the problem.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
class HelloWorld
{
public static void main(String[] args)
{
System.out.println("Hello World!");
}
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Copying the missing file to the System32 folder.
Looks like a possible for apps that embed the JVM.