in the last 20mins I did the following

1. Create a new DMD/LDC project

2. Added the code

import std.stdio;
import core.sys.windows.windows;
import std.array, std.conv;

int main(string[] argv)
{

	wchar* pCmd = cast(wchar*)to!wstring(argv.join(" ")).ptr;

	
    STARTUPINFO si;
    //ZeroMemory( &si, sizeof(si) );
    si.cb = si.sizeof;
    PROCESS_INFORMATION pi;
    //ZeroMemory(&pi, sizeof(pi));

    // Start the child process.
    BOOL result = CreateProcess
    (
        NULL, // No module name (use command line)
        pCmd, // Command line
        NULL, // Process handle not inheritable
        NULL, // Thread handle not inheritable
        FALSE, // Set bInheritHandles to FALSE
        DETACHED_PROCESS, // Detach process
        NULL, // Use parent's environment block
        NULL, // Use parent's starting directory
        &si, // Pointer to STARTUPINFO structure
        &pi // Pointer to PROCESS_INFORMATION structure (returned)
    );
    if (result) return 0;

    wchar[2048] msg;
    FormatMessage
    (
        FORMAT_MESSAGE_FROM_SYSTEM,
        null,
        GetLastError(),
        cast(uint)MAKELANGID(LANG_NEUTRAL, SUBLANG_SYS_DEFAULT),
        msg.ptr, cast(uint)2048,
        null
    );
	
    writeln(msg[0..lstrlen(msg.ptr)]);

    return -1;
}

3. Modified the command args in the options. Added cmd /c echo hello

4. Then went to debug it by putting a bp on the first line so I could check and ran it. Guess what? The program opened and closed. I've ran in to this problem before.

5. I added a bunch of bp's thinking it was just a problem with the first one(as that is how I get around it before).

6. Ran the program. Same thing. Ran the program. Same thing. I noticed that the bp's were turning white the split second the program was active.

hmmm... I then noticed the program was being built for x64.

7. I then changed it to x86 and voilà!

So, there is some issue with x64 and visual d's debugging in visual studio. That is the only file in the project. If it works on your system, keep trying until it doesn't!

On 18.06.2017 16:17, Mike B Johnson wrote:
> So, there is some issue with x64 and visual d's debugging in visual studio. That is the only file in the project. If it works on your system, keep trying until it doesn't!

As you expected, its not simple to reproduce. I have not managed to do so.

Could you specify a few more details:

- Visual D version?
- VS version?
- Which Configuration selected?
- dmd version?
- ldc version (in case you switched to "LDC Debug")?
- selected debug engine?

Slightly unrelated, but one thing that often bothers me: if you open the project configuration dialog, VS doesn't always show the current configuration (but the last edited one), so you edit options that don't seem to have any effect.

On 18.06.2017 16:50, Rainer Schuetze wrote:
> 
> 
> On 18.06.2017 16:17, Mike B Johnson wrote:
>> So, there is some issue with x64 and visual d's debugging in visual studio. That is the only file in the project. If it works on your system, keep trying until it doesn't!
> 
> As you expected, its not simple to reproduce. I have not managed to do so.
> 
> Could you specify a few more details:
> 
> - Visual D version?
> - VS version?
> - Which Configuration selected?
> - dmd version?
> - ldc version (in case you switched to "LDC Debug")?
> - selected debug engine?
> 
> Slightly unrelated, but one thing that often bothers me: if you open the project configuration dialog, VS doesn't always show the current configuration (but the last edited one), so you edit options that don't seem to have any effect.

I could produce an issue when starting the mago debugger for the first time after firing up VS2015: it showed an error, though, instead of not doing anything at all. Maybe it's a different effect of the same problem. I have added a work around that fixes it for me: https://ci.appveyor.com/project/rainers/visuald/build/job/5a92e21e7hxgty4b/artifacts

BTW: the output window should show whether symbols for your application have been loaded. If not, you get the behavior that you reported.

On Sunday, 18 June 2017 at 17:43:20 UTC, Rainer Schuetze wrote:
>
>
> On 18.06.2017 16:50, Rainer Schuetze wrote:
>> 
>> 
>> On 18.06.2017 16:17, Mike B Johnson wrote:
>>> So, there is some issue with x64 and visual d's debugging in visual studio. That is the only file in the project. If it works on your system, keep trying until it doesn't!
>> 
>> As you expected, its not simple to reproduce. I have not managed to do so.
>> 
>> Could you specify a few more details:
>> 
>> - Visual D version?
>> - VS version?
>> - Which Configuration selected?
>> - dmd version?
>> - ldc version (in case you switched to "LDC Debug")?
>> - selected debug engine?
>> 
>> Slightly unrelated, but one thing that often bothers me: if you open the project configuration dialog, VS doesn't always show the current configuration (but the last edited one), so you edit options that don't seem to have any effect.
>
> I could produce an issue when starting the mago debugger for the first time after firing up VS2015: it showed an error, though, instead of not doing anything at all. Maybe it's a different effect of the same problem. I have added a work around that fixes it for me: https://ci.appveyor.com/project/rainers/visuald/build/job/5a92e21e7hxgty4b/artifacts
>
> BTW: the output window should show whether symbols for your application have been loaded. If not, you get the behavior that you reported.

Didn't work ;/

All I get on the output wndow is

"
C:\Windows\System32\dbghelp.dll unloaded.
The thread 0x1ea4 has exited with code -1 (0xffffffff).
The thread 0x1390 has exited with code -1 (0xffffffff).
The thread 0x1ac has exited with code -1 (0xffffffff).
The program '[492] Async.exe' has exited with code -1 (0xffffffff).
"

On 18.06.2017 20:25, Mike B Johnson wrote:
> 
> Didn't work ;/
> 
> All I get on the output wndow is
> 
> "
> C:\Windows\System32\dbghelp.dll unloaded.
> The thread 0x1ea4 has exited with code -1 (0xffffffff).
> The thread 0x1390 has exited with code -1 (0xffffffff).
> The thread 0x1ac has exited with code -1 (0xffffffff).
> The program '[492] Async.exe' has exited with code -1 (0xffffffff).
> "

It seems the debug engine is only attached to the process when it starts terminating. Nothing cut off at the top? Strange.

Please try switching to the Visual Studio debug engine on the project debugger configuration page. This still uses mago as the D expression evaluator, but has all the other features of the VS debugger. It's actually the new and preferred way to run the debugger since the last Visual D release, especially with mixed languages.

On Sunday, 18 June 2017 at 21:02:12 UTC, Rainer Schuetze wrote:
>
>
> On 18.06.2017 20:25, Mike B Johnson wrote:
>> 
>> Didn't work ;/
>> 
>> All I get on the output wndow is
>> 
>> "
>> C:\Windows\System32\dbghelp.dll unloaded.
>> The thread 0x1ea4 has exited with code -1 (0xffffffff).
>> The thread 0x1390 has exited with code -1 (0xffffffff).
>> The thread 0x1ac has exited with code -1 (0xffffffff).
>> The program '[492] Async.exe' has exited with code -1 (0xffffffff).
>> "
>
> It seems the debug engine is only attached to the process when it starts terminating. Nothing cut off at the top? Strange.
>
> Please try switching to the Visual Studio debug engine on the project debugger configuration page. This still uses mago as the D expression evaluator, but has all the other features of the VS debugger. It's actually the new and preferred way to run the debugger since the last Visual D release, especially with mixed languages.

Doesn't work. Nothing is cut off. the x86 version is loading a bunch of symbols so maybe it is just a path issue? Is so then it should print a proper error message for it. I'll try to play around with the paths and see.

On 20.06.2017 02:05, Mike B Johnson wrote:
> On Sunday, 18 June 2017 at 21:02:12 UTC, Rainer Schuetze wrote:
>>
>>
>> On 18.06.2017 20:25, Mike B Johnson wrote:
>>>
>>> Didn't work ;/
>>>
>>> All I get on the output wndow is
>>>
>>> "
>>> C:\Windows\System32\dbghelp.dll unloaded.
>>> The thread 0x1ea4 has exited with code -1 (0xffffffff).
>>> The thread 0x1390 has exited with code -1 (0xffffffff).
>>> The thread 0x1ac has exited with code -1 (0xffffffff).
>>> The program '[492] Async.exe' has exited with code -1 (0xffffffff).
>>> "
>>
>> It seems the debug engine is only attached to the process when it starts terminating. Nothing cut off at the top? Strange.
>>
>> Please try switching to the Visual Studio debug engine on the project debugger configuration page. This still uses mago as the D expression evaluator, but has all the other features of the VS debugger. It's actually the new and preferred way to run the debugger since the last Visual D release, especially with mixed languages.
> 
> Doesn't work. Nothing is cut off. the x86 version is loading a bunch of symbols so maybe it is just a path issue? Is so then it should print a proper error message for it. I'll try to play around with the paths and see.

Did you have success debugging your x64 builds? I've committed a small change to the mago debugger, maybe it helps. There is a new installer here: https://github.com/dlang/visuald/releases/tag/v0.45.0-rc1

If that still fails: Does debugging a C++ application work? If it does, you could try exchanging the debug executable in the C++ project with the D executable and see if that can be debugged.

On 18.06.2017 20:25, Mike B Johnson wrote:
>> I could produce an issue when starting the mago debugger for the first time after firing up VS2015: it showed an error, though, instead of not doing anything at all. Maybe it's a different effect of the same problem. I have added a work around that fixes it for me: https://ci.appveyor.com/project/rainers/visuald/build/job/5a92e21e7hxgty4b/artifacts 
>>
>>
>> BTW: the output window should show whether symbols for your application have been loaded. If not, you get the behavior that you reported.
> 
> Didn't work ;/
> 
> All I get on the output wndow is
> 
> "
> C:\Windows\System32\dbghelp.dll unloaded.
> The thread 0x1ea4 has exited with code -1 (0xffffffff).
> The thread 0x1390 has exited with code -1 (0xffffffff).
> The thread 0x1ac has exited with code -1 (0xffffffff).
> The program '[492] Async.exe' has exited with code -1 (0xffffffff).
> "

After installing VS2017 on a fresh Win10 install I could reproduce this issue: the mago debug engine failed to load the symbols when only VS2017 is installed, because the COM-CLSID to load msdia140.dll changed. Switching to the VS debug engine worked, though.

Should be fixed in the next release.

On Saturday, 22 July 2017 at 12:54:17 UTC, Rainer Schuetze wrote:
>
>
> On 18.06.2017 20:25, Mike B Johnson wrote:
>>> [...]
>> 
>> Didn't work ;/
>> 
>> All I get on the output wndow is
>> 
>> "
>> C:\Windows\System32\dbghelp.dll unloaded.
>> The thread 0x1ea4 has exited with code -1 (0xffffffff).
>> The thread 0x1390 has exited with code -1 (0xffffffff).
>> The thread 0x1ac has exited with code -1 (0xffffffff).
>> The program '[492] Async.exe' has exited with code -1 (0xffffffff).
>> "
>
> After installing VS2017 on a fresh Win10 install I could reproduce this issue: the mago debug engine failed to load the symbols when only VS2017 is installed, because the COM-CLSID to load msdia140.dll changed. Switching to the VS debug engine worked, though.
>
> Should be fixed in the next release.

I installed a fresh VS2017 and the latest beta visual D and same issues. As of today, was this suppose to be fixed?

On 31.07.2017 19:51, Johnson Jones wrote:
> On Saturday, 22 July 2017 at 12:54:17 UTC, Rainer Schuetze wrote:
>>
>>
>> On 18.06.2017 20:25, Mike B Johnson wrote:
>>>> [...]
>>>
>>> Didn't work ;/
>>>
>>> All I get on the output wndow is
>>>
>>> "
>>> C:\Windows\System32\dbghelp.dll unloaded.
>>> The thread 0x1ea4 has exited with code -1 (0xffffffff).
>>> The thread 0x1390 has exited with code -1 (0xffffffff).
>>> The thread 0x1ac has exited with code -1 (0xffffffff).
>>> The program '[492] Async.exe' has exited with code -1 (0xffffffff).
>>> "
>>
>> After installing VS2017 on a fresh Win10 install I could reproduce this issue: the mago debug engine failed to load the symbols when only VS2017 is installed, because the COM-CLSID to load msdia140.dll changed. Switching to the VS debug engine worked, though.
>>
>> Should be fixed in the next release.
> 
> I installed a fresh VS2017 and the latest beta visual D and same issues. As of today, was this suppose to be fixed?

It hasn't been released until now: https://github.com/dlang/visuald/releases/tag/v0.45.0