I've had success with Sysinternals Process Explorer. With this, you can search to find what process(es) have a file open, and you can use it to close the handle(s) if you want. Of course, it is safer to close the whole process. Exercise caution and judgement.
To find a specific file, use the menu option Find->Find Handle or DLL... Type in part of the path to the file. The list of processes will appear below.
If you prefer command line, Sysinternals suite includes command line tool Handle, that lists open handles.
Examples
c:\Program Files\SysinternalsSuite>handle.exe |findstr /i "e:\" (finds all files opened from drive e:\"c:\Program Files\SysinternalsSuite>handle.exe |findstr /i "file-or-path-in-question"
(My initial answer was premature. As promised, I've rewritten it after having gotten everything working.)
First of all, I've found that in general iSCSI-boot-enabling software is half-baked, and the disparate systems involved interoperate very poorly. For this reason I recommend instead going with a hardware-based solution such as iSCSI HBAs if possible. With that said I'll relate my experiences here in case it helps anyone.
To summarize what I found (I'm assuming you've set up DHCP and TFTP for PXE and an iSCSI target and have gotten as far as chaining to gPXE or iPXE):
gPXE and iPXE never write multiple NICs into the iBFT (iSCSI Boot Firmware Table), and this can impact Windows Server. I have discussed this problem in detail in a separate question here.
In addition to the above design limitation, gPXE has an actual bug that likewise affects systems with multiple network ports. I'll explain below. In order to avoid this bug, I used the "UNDI only" build of gPXE. This prevents gPXE from accessing the NICs directly and makes it instead use an API provided by the NIC's PXE loader. This makes gPXE think there is only one network port (the one it was loaded on), and this evades the bug. I am not sure if this bug is present in newer iPXE versions.
I was initially confused about the keep-san option in gPXE/iPXE. The keep-san flag affects gPXE's behaviour only if the boot fails. Therefore, this option is needed only on the very first boot when the installation is started.
Windows Server (at least 2012 and probably others) apparently does not tolerate moving the iSCSI initiator that provides its system disk from one network port to another. If Windows is booted from an initiator on a different network port than the one to which it was installed, Windows will crash (BSOD and/or reboot) during boot, at the handoff to the MS initiator.
There is an acknowledged feature/issue in Windows Server (2003 and up) where it will use the gateway, if one is specified, to access the target, even if the target is on the local subnet. If the gateway is unavailable or doesn't route back onto the same port, the boot will fail at the handoff to the MS initiator. Make sure no gateway setting is given out by the DHCP if one isn't needed.
The gPXE bug I mention above involves the iBFT (iSCSI Boot Firmware Table). This is an object which is placed into memory by the pre-boot system which contains information about the NICs, iSCSI initiator, and the iSCSI target to use as the system disk. The OS uses this information to continue booting once it switches to protected mode. The format is specified here.
Suspecting a problem in the information gPXE was placing in the iBFT, I programmed a boot sector which dumps the contents of the iBFT to the screen. Using this I found that the data written by gPXE is under certain circumstances erroneous.
As mentioned, gPXE only writes one NIC record into the iBFT, but in some situations, the information written to that one NIC record is jumbled up. The MAC address and PCI address will correspond to one NIC, but the local IP and gateway addresses will correspond to another. This is most likely to happen if the SAN is not on the first NIC.
To add to the confusion, this incorrect iBFT information is written if gPXE boots automatically, but when booting from gPXE's command prompt, depending on the exact sequence of commands entered, the correct information may be written. Throw in the fact that Windows will manifest symptoms identical to those caused by this bug if its NIC has been changed (even given a correct iBFT), and you can see why I tore my hair out.
By the way, in my original question I had thought that it was working for Server 2008 R2 but not Server 2012. (I'm editing that out as it's misleading.) I suspect there's actually no difference in their underlying behaviour and that the different outcomes owed to the subtleties of the above problems and minor variations in my tests.
Best Answer
During windows startup, try installing server core, rather than the "full" version. As this won't install a GUI, if it installs without issue, the problem is likely to be in the default video drivers for whatever graphics card you have. You may need to slipstream new drivers into the install media.
If you can't install the core version either, then the problem may lie with either the media you're using, or a problem with the hardware. I've seen everything from bad video cards to bad power supplies cause issues with installing windows. Try to test the media on another machine.