[Bug] Project from external hdd fails to load debug symbols

When building the game dll and running from Visual Studio 2013, the engine fails to find the pdb file
ProjectDir\Binaries\Win64\UE4Editor-Prototype1-Win64-DebugGame.pdb

Checking the output log in VS showed that the file path was correct except for the drive letter, which was either “C:1” or “C:0”. This changed when I unplugged and replugged my external hdd.

Is there anyway to get information to get the built path of where the pdb file is? Or what writes the pdb file path reference used by the unreal build tool?

Its worth noting that moving the project folder onto the C drive itself fixed the issue.

I’m not entirely sure what is happening. The entire project loads and runs from visual studio with no errors. All other drive references are found and used correctly, the project itself does run and debug, the only thing that breaks is that I cant place breakpoints because of this.

Thanks in advance for any info and if this is a bug or something I’ve managed to do myself then apologies

Hello ,

Since I can’t find any information on this particular issue, the first thing we should try is a newer version of the engine. This way we can see if there have been any fixes added since 4.9 that could resolve this problem. Could you try downloading 4.11 from the Epic Games Launcher (be sure to include the debug symbols, as they started becoming optional after 4.9) and see if it’ll work correctly? Even if you’re not looking to upgrade, knowing that it is fixed in a newer version will help in finding the solution.

I’ll have a look later as im currently working for a university degree and will finish soon.

But the systems only have 4.9.2 so I will upgrade afterwards and investigate further to see if the problem still occurs

We haven’t heard from you in a while . Have you had a chance to try upgrading as of yet? If not, please take your time and let me know when you have via a comment. In the meantime, I’ll be using this post to this issue as resolved for tracking purposes. Once you’re ready, a comment will reopen it so that we can continue.

I am experiencing exactly the same problem right now. I have found some really strange things about this:

I have bought new NVMe ssd that I installed and formatted. Then I checked out from SVN my project onto this new ssd. When I builded the project and run it with debug, I noticed that some pdb files aren’t loaded and they appear in modules window (visual studio/debug/windows/modules) with these malformed paths. I have searched all files in my project for occurence of string “D:1” and found nothing that matters. Then I checked my drive in device manager and I have found some problem with it:

Device SCSI\Disk&Ven_NVMe&Prod_APS-SE20Q-2T\5&639fd43&4&000000 was not migrated due to partial or ambiguous match.

Last Device Instance Id: SCSI\Disk&Ven_OCZ-VERT&Prod_EX4\4&26e76114&0&000400
Class Guid: {4d36e967-e325-11ce-bfc1-08002be10318}
Location Path: 
Migration Rank: 0xF000FF001001F120
Present: false
Status: 0xC0000719

I found similiar problem with NVM Express controller:

Device PCI\VEN_1987&DEV_5012&SUBSYS_50121987&REV_01\4&36aec469&0&00E8 was not migrated due to partial or ambiguous match.

Last Device Instance Id: {8e7bd593-6e6c-4c52-86a6-77175494dd8e}\MsVhdHba\1&3030e83&0&01
Class Guid: {4d36e97b-e325-11ce-bfc1-08002be10318}
Location Path: 
Migration Rank: 0xF000FFFFFFFFF122
Present: false
Status: 0xC0000719

APS-SE20Q-2T is my new drive and OCZ-VERT is other one (ocz vertex drive).
Before I installed my new drive, the ocz vertex drive had 2 partitions - UEFI boot partition and EXT4 partition on which linux was installed.

I have searched windows registry for occurences of “D:1” and i have found, that there are entries in windows firewall with path to my project executable that are malformed (“D:1\svn\project\engine\binaries\win64\ue4editor-win64-debuggame.exe”). This malformed path (even if i skip drive part) does not correspond to path of executable!
I deleted those entries from windows firewall, run my project, accepted windows firewall prompt, and then I have found that those malformed entries were added again.

I don’t know how to fix it. I tried everything - disable ocz vertex drive in bios, physically disconnect ocz drive, uninstall drive in device manager, uninstall NVM Express controller, install chipset drivers.

If someone has the solution (other than reinstalling windows) or knows what the hell is going on, then PLEASE leave a comment.

Reinstall of windows did not helped me to solve this problem (which means, that this is some bug carried with the data of partitions itself (partition table?)).

I have managed to find solution for me (but I still don’t know what exacly was heppening, and i don’t know how to apply my fix if malformed paths point to system partition: usually “C:”):

  1. Go to disk management (run “diskmgmt.msc”)
  2. Right click on partition to which malformed paths point to (in my case “D:1” means partition “D:”)
  3. Click "Change Drive Letter and Paths…"
  4. In window that pops up you should see your partition, now click delete and confirm (this will not delete partition, it will only delete drive letter, partition will not be seen in windows explorer after that)
  5. Right click the same partition again
  6. Click "Change Drive Letter and Paths…"
  7. Assing new letter to this partition (i have assigned “D:” again)

After that problem disappeared. If your malformed paths point to system partition, then obviously you have to find another way (maybe running second windows?).

1 Like

well, i met this issue after i use striped volume (RAID 0) on win10, change the Driver Letter and Change it back do solve the issue, thanks