Re: cv2pdb: cannot add symbols to module, probably msobj140.dll missing
On Monday, 21 August 2017 at 06:16:49 UTC, Rainer Schuetze wrote: On 21.08.2017 05:24, Johnson wrote: On Monday, 21 August 2017 at 03:18:38 UTC, Johnson wrote: [...] This just started happening too and a few hours ago I upgraded VS, so maybe the msobj140.dll changed and broke cv2pdb? I copied it to the cv2pdb dir so it should have no trouble finding it. I've also cleaned the dir. It seems it's doing it on about everything I change. Going to reboot to see if that helps. Unfortunately, the VS2017 15.3.1 update seems to cause quite some trouble. Bad linker (breaks TLS), bad vcvars*.bat (change current directory), and this issue, too. I guess they changed something about the (undocumented) interface to the respective DLLs. ;/ That sucks ;/ I guess I might just have to install VS2015, or does that have issues too? Any idea what might be the best VS version that is most compatible with Visual D?
Re: cv2pdb: cannot add symbols to module, probably msobj140.dll missing
On Monday, 21 August 2017 at 03:18:38 UTC, Johnson wrote:
All of a sudden I'm getting this error. All I did was comment
out a huge block of code so I could check something. The code
compiles but the pdb conversion gives me that error ;/
Uncommenting out the code allows it to work again. I can't see
why the code I'm commenting out would give that error ;/
Deleting the code also produces the same result.
It seems to be in use with GTK and event handlers. The handlers
are completely isolated yet are somehow causing the problem.
You won't believe this, I'm sure, but
//Dialog.addOnDestroy((Widget w) { });
causes the error! Must be some serious bug! Uncommenting allows
the code to build fine.
I tried restarting visual D with no luck ;/
This just started happening too and a few hours ago I upgraded
VS, so maybe the msobj140.dll changed and broke cv2pdb? I copied
it to the cv2pdb dir so it should have no trouble finding it.
I've also cleaned the dir. It seems it's doing it on about
everything I change. Going to reboot to see if that helps.
cv2pdb: cannot add symbols to module, probably msobj140.dll missing
All of a sudden I'm getting this error. All I did was comment out
a huge block of code so I could check something. The code
compiles but the pdb conversion gives me that error ;/
Uncommenting out the code allows it to work again. I can't see
why the code I'm commenting out would give that error ;/
Deleting the code also produces the same result.
It seems to be in use with GTK and event handlers. The handlers
are completely isolated yet are somehow causing the problem.
You won't believe this, I'm sure, but
//Dialog.addOnDestroy((Widget w) { });
causes the error! Must be some serious bug! Uncommenting allows
the code to build fine.
I tried restarting visual D with no luck ;/
Re: Debugging Visual D using Visual D
On Wednesday, 16 August 2017 at 19:35:19 UTC, Rainer Schuetze
wrote:
On 16.08.2017 21:18, Johnson Jones wrote:
What's strange is that with your changes, privateregistry
seems to use them... but it still loads the old(I think)
visualD because when I try the debug the BP's are not hit and
the module shows the original visualD directory.
The Visual D installer adds the extension to the VS
installation ("c:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\Common7\IDE\Extensions\Rainer
Schuetze\VisualD") so it is immediately available for all users
and suffixes.
You can move it to
"%HOME%\AppData\Local\Microsoft\VisualStudio\15.0_\Extensions\Rainer Schuetze\VisualD" to load it only with the version without suffix. With both the system wide extension and the one in the "Exp" folder, the extension from the user folder took precedence for me, though.
If you run "devenv /RootSuffix Exp /Log" VS writes a log into
"%APPDATA%\Roaming\Microsoft\VisualStudio\15.0_Exp\ActivityLog.xml" that also lists detected extensions.
I completely removed the `Extensions\Rainer Schuetze` directories
in all visual studio folders that I know of:
C:\Program Files (x86)\Microsoft Visual
Studio\2017\Enterprise\IDE\Extensions
C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469e
C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469eExp
Running visual studio still loads Visual D. It seems that it
doesn't even use the visuald.pkgdef.
Obviously I have those entries in the registry. Which it seems it
pulls from and either doesn't use the extensions folder at all on
my system or is overridden by the registry entries? If that's the
case, how can it be worked around? If not, what else might it be?
If visuald.pkgdef is suppose to be what visual studio uses to
load visual D as an extension, does it import that in to the
registry and then use the registry or does it always use the
pkgdef file?(which doesn't seem to be the case, as, again, visual
D is loading with visual studio without any of those pkgdef's)
What I'm afraid of is that deleting the registry keys will not do
any good, they will just be re-imported by loading the pkgdef(or
not, in which case Visual D won't be found at all) and then the
main registry keys will be used for the Exp, like it is now.
Basically visual studio is not loading the pkgdef files either at
all or only once, or every time but not allow them to overwrite
the registry keys, or something else is going on that I can't
seem to figure out.
Re: Debugging Visual D using Visual D
On Wednesday, 16 August 2017 at 06:58:49 UTC, Rainer Schuetze wrote: On 16.08.2017 08:32, Rainer Schuetze wrote: On 16.08.2017 04:49, Johnson wrote: VisualD.dllC:\Program Files (x86)\VisualD\Debug\VisualD.dll N/AYesSymbols loaded. C:\Program Files (x86)\VisualD\Debug\VisualD.pdb229 0.45.1-rc212/31/1969 7:00 PM13FB-143C* [8972] devenv.exe VisualD.dllC:\Program Files (x86)\VisualD\VisualD.dllN/A YesCannot find or open the PDB file.2710.45.1-rc2 12/31/1969 7:00 PM 18D4-1904E000*[8972] devenv.exe I was finally able to get it to work. Something is wonky. I think it's when I use a normal VS side by side with the experimental that the experimental can't find the symbols and somehow the registry changes I made got reset. So far it is working(I can hit BP's) but it's still basically the same scenario in that I have to completely shut down VS in order to reload visualD. Before I could automate because the normal visual studio instance could stay open... but it seems like it screws up the debugging symbols and such. I could try to use another, different exp instance(different registry) but I feel the same problem might occur. But I guess it's better than nothing. Good to hear it (kind of) works now. VS2015 also resets the configuration rather often, so it's good to automate the patching. I don't have troubles with exchanging the debug DLL while having the normal VS instance running. Maybe you have experimented with registry changes that now cause the debug DLL to be loaded there, too? Reinstalling Visual D should help in that case (though that will trigger rebuilding the user configuration). I've tried to figure out why both DLLs are actually loaded (it has been bugging me before, too), but could not find the cause yet. I managed to load the Debug DLL into the "experimental" VS without any (explicit) registry patching: 1. delete HOME%\AppData\Local\Microsoft\VisualStudio\15.0_Exp\privateregistry.bin to make sure to start from scratch 2. copy "c:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\Rainer Schuetze\VisualD" to "%HOME%\AppData\Local\Microsoft\VisualStudio\15.0_Exp\Extensions\Rainer Schuetze\VisualD" 3. replace paths in Extensions\Rainer Schuetze\VisualD\0.45\visuald.pkgdef to point to the debug DLL 4. start "devenv /RootSuffix Exp" 5. enable "Visual D" in the "Extensions and Updates..." dialog 6. restart VS This even doesn't load the DLL twice for me. This isn't working for me, even though it looks like it should. Those values in the pkgdef are exactly the ones I replaced in the privateregistry hive, but it seems that for some reason it is not being used ;/ (since my changes are not propagating to it) This should work as this is really no different that what I was doing except it is more of the correct way. I'm not sure what's going on but I'll try and figure it out. I probably need to use a clean instance of VS It seems I have something weird going on. I have 15.0 15.0_4d0b469e 15.0_4d0b469eExp 15.0Exp which is empty except for a path containing VSTemplateStore.pkgdef and I don't believe this existed yesterday. I think I just created it with the util I used as I was trying to reset the exp instance(which I thought was the 3rd one). I'm not sure where the others came from but I'm going to create a new rootsuffix and try everything on that. I guess the 15.0_4d0b469eExp is a _4d0b469eExp suffix and hence I'm not loading it ;/ Ok, I ran CreateExpInstance /create /VSInstance=15.0 /RootSuffix=VisualDExp and it created a 15.0VisualDExp dir. So, looks like the 15.0Exp was what I just created and it wasn't being used when I ran /RootSuffix=Exp.. which I guess, because it didn't exist, just used the original data. I ran devenv.exe /RootStuffix VisualDExp and it created 15.0_4d0b469eVisualDExp So, something is funky. I guess 15.0_4d0b469e is the version. It loads, though, Visual D, so it is picking up the extensions from the original. This seems to be a problem with Visual Studio ;/ Yeah, so, tried with a fresh exp copied all the stuff you mentioned, checked the files and same thing. I'm using enterprise on windows 10 creators so there might be bugs. It's clearly not loading the package changes I made so either it's bugged or it's loading them from a different place. I'll try again tomorrow and see if things change ;/
Re: Debugging Visual D using Visual D
VisualD.dll C:\Program Files (x86)\VisualD\Debug\VisualD.dll N/A Yes Symbols loaded. C:\Program Files (x86)\VisualD\Debug\VisualD.pdb 229 0.45.1-rc2 12/31/1969 7:00 PM 13FB-143C* [8972] devenv.exe VisualD.dll C:\Program Files (x86)\VisualD\VisualD.dll N/A Yes Cannot find or open the PDB file. 271 0.45.1-rc2 12/31/1969 7:00 PM 18D4-1904E000* [8972] devenv.exe I was finally able to get it to work. Something is wonky. I think it's when I use a normal VS side by side with the experimental that the experimental can't find the symbols and somehow the registry changes I made got reset. So far it is working(I can hit BP's) but it's still basically the same scenario in that I have to completely shut down VS in order to reload visualD. Before I could automate because the normal visual studio instance could stay open... but it seems like it screws up the debugging symbols and such. I could try to use another, different exp instance(different registry) but I feel the same problem might occur. But I guess it's better than nothing.
Re: Visual D no bp's on x64
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 (0x). The thread 0x1390 has exited with code -1 (0x). The thread 0x1ac has exited with code -1 (0x). The program '[492] Async.exe' has exited with code -1 (0x). " 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.
Re: Visual D no bp's on x64
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 (0x). The thread 0x1390 has exited with code -1 (0x). The thread 0x1ac has exited with code -1 (0x). The program '[492] Async.exe' has exited with code -1 (0x). "
Visual D no bp's on x64
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( , sizeof(si) );
si.cb = si.sizeof;
PROCESS_INFORMATION pi;
//ZeroMemory(, 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
, // Pointer to STARTUPINFO structure
// 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!
