Debugging with Visual Studio 2022

VegaMega wrote on 10/2/2024, 11:01 AM

I was wondering if anybody has got debugging working from within Visual Studio 2022 with Vegas 21 or 22?

My dll's work perfectly when loaded from within Vegas. So my build environment is all okay. I build against .Net Framework 4.8.

In the debug section of the project I have:

  • Start external program:
    • C:\Program Files\VEGAS\VEGAS Pro 22.0\vegas220.exe
  • Command line arguments:
    • -SCRIPT:D:\scripts\VegasPro\Trial06\Trial06\bin\Debug\Trial06.dll

But this results in:

The program '[139920] vegas220.exe' has exited with code 0 (0x0).

(Actually pretty fast, way faster then starting Vegas usually takes.)

 

I tried numerous things without success:

  • Started VS as Administrator
  • No command line argument
  • Ran SysInternals' process explorer and looked for errors that made any hint to a cause
  • Changed external program into a random other executable (that starts fine)

 

An alternative solution may be to use 'attach to process' when Vegas is already running. But I could not get that to work either. It just does not stop at my break point. I tried putting a messagebox and when the script was at the messagebox, add my breakpoint and click okay in the messagebox. But that did not work either. So any advise on how to do this may also be a great solution as not having to start Vegas each time would be a good time saver and with the "vegas.UnloadScriptDomainOnScriptExit = true;" in the script, it does not have to be closed again before you can rebuild a new version.

 

 

 

Comments

jetdv wrote on 10/2/2024, 11:50 AM

@VegaMega I did this tutorial when VEGAS Pro 18 was current:

I just tested and VEGAS Pro 18 does still work as expected. So does VEGAS Pro 19. Starting with VEGAS Pro 20 and newer, VEGAS never even starts. This is using Visual Studio 2015.

I typically just use MessageBox(...) now to show progress in a routine and variable values as needed to debug. I've found it's really easy to debug that way.

VegaMega wrote on 10/2/2024, 12:38 PM

@jetdv I am doing exactly as the video but it just does not start Vegas. I was hoping there is some magix trick to get this to work. But when I read you correctly, it is a bug that started from Vegas 20. Well I only have 21 and 22, so I am stuck with getting debug to work and there is no hope for a work around? right?

Also no hope for the attach to process method?

Time-Tree wrote on 10/2/2024, 4:49 PM

@jetdv I am doing exactly as the video but it just does not start Vegas. I was hoping there is some magix trick to get this to work. But when I read you correctly, it is a bug that started from Vegas 20. Well I only have 21 and 22, so I am stuck with getting debug to work and there is no hope for a work around? right?

Also no hope for the attach to process method?

I'm not sure if this is an issue with using the "Trial" Version of 21 or 22, although, if anyone else has Vegas Pro 21 or 22 and knows how to debug, that would be nice. Unfortunately, I don't have much time to figure out how to help with this any further.

jetdv wrote on 10/2/2024, 9:02 PM

@Time-Tree mine are not trial versions.

VegaMega wrote on 10/3/2024, 6:33 AM

@Time-Tree mine are not trial versions.

Mine neither.

 

Also when checking the "enable native code debugging" checkbox in the debug options, there is some intreresting output shown:

  • Exception thrown at 0x00007FFC2C45FABC in vegas220.exe: Microsoft C++ exception: long at memory location 0x00000000005AF470.

And also there sometimes is some http output from npmproxy.dll with status 204 (=No Content). But it looks mostly like google analytics that is embedded into Vegas. It retries a couple of times and ends with "StopTracking() => TerminatedEvent" followed by "The thread 111724 has exited with code 0 (0x0). 'vegas220.exe' (Win32): Unloaded 'C:\Program Files\VEGAS\VEGAS Pro 22.0\gahelper_rel_u_dynMFC_x64_vc16.dll'" and from there all treads exit and the whole thing closes down. That might be a coincidence but it may also be a hint to the cause. But I have no idea yet on how to continue this path.

Meanwhile, I'll be re-visiting the attach to process method again to see if I can get any closer with that option.

 

 

 

    Harold-Linke wrote on 10/3/2024, 11:53 AM

    @VegaMega, if I remember well this is unfortunately a security feature introduced with VP20. I think the idea is to prevent debugging and decompiling the code. Unfortunately for us developers this is a pain and makes debugging a bit more difficult.

    With attach to the process I was able to debug my own code some tme ago with VP21. I have not tested with VP22.

    Jack S wrote on 10/4/2024, 5:21 AM

    @VegaMega I'm with @jetdv on this. I always use message boxes to debug.

    My system
    Genshin Infinity Gaming PC
    Motherboard Gigabyte H610M H: m-ATX w/, USB 3.2, 1 x M.2
    Power Supply Corsair RM750X
    Intel Core i7-13700K - 16-Core [8P @ 3.4GHz-5.4GHz / 8E @ 2.50GHz-4.20GHz]
    30MB Cache + UHD Graphics, Ultimate OC Compatible
    Case Fan 4 x CyberPowerPC Hyperloop 120mm ARGB & PWM Fan Kit
    CPU Fan CyberPowerPC Master Liquid LITE 360 ARGB AIO Liquid Cooler, Ultimate OC Compatible
    Memory 32GB (2 x 16GB) DDR5/5200MHz Corsair Vengeance RGB
    MSI GeForce RTX 4060 Ti 8GB - Ray Tracing Technology, DX12, VR Ready, HDMI, DP
    System drive 1TB WD Black SN770 M.2 NVMe PCIe SSD - 5150MB/s Read & 4900MB/s Write
    Storage 2 x 2TB Seagate BarraCuda SATA-III 6.0Gb/s 7200RPM
    Windows 11 Home (x64)
    Monitors
    Generic Monitor (PHL 222V8) connected to GeForce RTX 4060 Ti
    Generic Monitor (SAMSUNG) connected to iGPU

    Camcorder
    SONY Handycam HDR-XR550VE

    VegaMega wrote on 10/4/2024, 5:32 AM

    @VegaMega I'm with @jetdv on this. I always use message boxes to debug.

    Sure there are workarounds. I can debug with only one IO pin and a led. But it is far from ideal. Imagine a debugger like visual studio that allows you to really look at the objects in scope and expand these and find new properties/methods that you didn't know of. So much easier!

    I did not manage to get the attach to process work. Tried again for a couple of hours but no luck at all. I just cannot get it to stop at a breakpoint and the breakpoints are all inactive "no symbols have been loaded". Tried a bunch if things. If anyone has gotten this to work, please drop a few magic keywords on which I can continue this journey.

    wwaag wrote on 10/4/2024, 11:48 PM

    Another MessageBox user here.

    Here's a tip that can be a real time-saver when debugging scripts. One of the time-consuming (and annoying) aspects of debugging is just starting Vegas after a new build, which is certainly true if you can launch Vegas as part of the debugging process in VS. If you insert the following code into your script, you can leave Vegas open, make changes to your script in VS, build, switch to Vegas and immediately launch the changed script without having to restart Vegas each time. It saves a lot of time.

    vegas.UnloadScriptDomainOnScriptExit = true;

    I usually add this command near the beginning of the script. Note that it does not work for Extensions since they are loaded during Vegas startup.

    AKA the HappyOtter at https://tools4vegas.com/. System 1: Intel i7-8700k with HD 630 graphics plus an Nvidia RTX4070 graphics card. System 2: Intel i7-3770k with HD 4000 graphics plus an AMD RX550 graphics card. System 3: Laptop. Dell Inspiron Plus 16. Intel i7-11800H, Intel Graphics. Current cameras include Panasonic FZ2500, GoPro Hero11 and Hero8 Black plus a myriad of smartPhone, pocket cameras, video cameras and film cameras going back to the original Nikon S.

    ccscotty wrote on 10/11/2024, 5:03 PM

    I ran into this when I went from version 19 to 21. I learned that the change is intentional. In a way I understand their reasoning, but it's the classic situation of hurt your paying customers for "business reasons".

    https://www.vegascreativesoftware.info/us/forum/debugging-in-version-21-build-315-or-probably-previous-builds-too--145852/

    Since then I haven't done any major development on my scripts. I'll have to rework my existing code to route and handle everything through prompts. Though I don't know of an editing program with this level of scripting so it's a situation of dealing with whatever they decide to do.

    Like VegaMega said, there's a lot more to debugging than dealing with errors. Stepping through code can be extremely useful. Looking at objects and variables while running, etc.

    Overall version 21 has been a really unpleasant upgrade with loss of debugging and it's actual existing bugs. The current build 315 crashes when I try to do vertical aspect ratio videos, so I end up having to copy-paste my timeline from 21 to 19 to get things done. Not sure I want to reward the bad experiences I've had with 21 to buy and try out 22.

     

    jetdv wrote on 10/12/2024, 8:51 AM

    @ccscotty I really would try version 22... You can always test with the trial first but it really does have a lot of bug fixes in it.