Debugging doesn't seem to work

Aug 22, 2014 at 12:08 PM
If I set a breakpoint and then do Alt-F5 to start debugging, my script runs straight through and doesn't stop on the breakpoint. I tried also hitting the "Start Debugging" button in the Debug panel, and I got "The system cannot find the file specified" in the Debug Output panel.
Aug 22, 2014 at 1:07 PM
I cannot reproduce the problem so let's try to see that the debugging works in the 'default conditions'.

Can you please try these steps and let me know the outcome:
  1. Close npp
  2. Open npp
  3. Press "Create new script" button and enter the script name
  4. In "Breakpoints" tab click "Remove all"
  5. Place cursor inside of the "Main" method
  6. Press F9
  7. Press Alt+F5
Did it hit the breakpoint?
Aug 22, 2014 at 1:13 PM
No, it does not hit the breakpoint. I do see the red dot in the editor window, and I see the breakpoint listed on the Breakpoints tab.
Aug 22, 2014 at 1:26 PM
This is odd. It means that you do not have the plugin properly deployed.

Can you try to remove and add the plugin again? Not that I think there is a big chance it would help but just in case. May be somehow the debugger is not installed.

After the installation you must have C:\Program Files (x86)\Notepad++\plugins\CSScriptNpp\Mdbg\mdbg.exe present. Do you?
Aug 22, 2014 at 1:36 PM
If reinstall does not help can you test if the debugging outside of NPP is possible?
  1. With the brand new script press "Prepare script for distribution" button in the script project panel
  2. Select "script+engine" and press "Prepare" button
  3. In the prepared run.cmd file add '//x' to the end of the first line: cscs.exe "New Script#.cs" //x
  4. Double-click run.cmd file and try to select the debugger when prompted.
  5. Press F10
Did it attach the system debugger?

BTW what plugin version are you using and what is the OS?
Aug 23, 2014 at 3:19 AM
Edited Aug 23, 2014 at 3:21 AM
I tried the reinstall -- I do not have an Mdbg subdirectory, or an mdbg.exe. Debugging outside of NPP got me to start a new instance of VS, but then nothing happened inside of it.

I'm running Windows 7 Professional, NPP 6.6.8, CS-Script 1.0.28.
Aug 23, 2014 at 3:31 AM
Now I see that there's a 1.0.30 available from this site (1.0.28 was installed via Plugin Manager, and NPP/CS-Script report no updates available). If I install 1.0.30, debugging works fine -- but not if I choose Plugins -> CS-Script -> Debug. It only works if I hit Alt-F5 or the "Start Debugging" button in the Debug pane.
Aug 24, 2014 at 8:40 AM
Edited Aug 24, 2014 at 9:03 AM
> I do not have an Mdbg subdirectory, or an mdbg.exe
Great. This explains why you cannot debug with NPP. The plugin deployment was compromised on you PC. Why? Hard to tell. Plugin Manager is responsible for the installation of all plugins not plugins themselves. In fact the plugins have no control over the installations.

It is possible that somehow plugin MSI installation collided with the plugin manager. But I do not know if you ever used CS-Script.Npp MSI.

>Debugging outside of NPP got me to start a new instance of VS, but then nothing happened inside of it.
Good. It means that your environment can be used for debugging.
If you indeed want to debug this way then you need to finish step #4 and #5. This technique has nothing to do with neither CS-Script nor NPP. It is a standard way of attaching the system-wide debugger to the running CLR application.

>Now I see that there's a 1.0.30 available from this site (1.0.28 was installed via Plugin Manager, and NPP/CS-Script report no updates available)
Yes. Unfortunately Plugin manager is only propagating the updates every 3-4 month or so. Right now the official Plugin Manager repository has CS-Script.Npp version 1.0.30 but it does not make it available until the next Plugin Manager update cycle.

CS-Script.Npp plugin itself supports checking for updated from the about box. Checking is also done on It is also done on NPP startup unless it is disabled in the config file or there are the connectivity problems (no connection, proxy authentication is enabled).

Hard to tell (without investigating) what prevents it in your case, but may be because of the corrupted installation.

>If I install 1.0.30, debugging works fine.
Great. Then the debugging problem is solved. :o)

>...but not if I choose Plugins -> CS-Script -> Debug. It only works if I hit Alt-F5 or the "Start Debugging" button in the Debug pane.
And this is actually a defect. Thank you for reporting. I will publish the fix in a day or two.

Thank you for your feedback.
Aug 24, 2014 at 9:52 AM
I just published the fix (v1.0.31) for the menu item.

You can get it by clicking the plugins "Check for Updates" button in the AboutBox.
Aug 25, 2014 at 3:10 AM
"Check for Updates" sees .31, but says it can't download the binaries and redirects me to the Codeplex page. I downloaded the 7z file and unzipped into the Plugins folder, but now when I start NPP I get an "Unknown Exception" dialog, and the plugin is not available in the Plugins menu. I tried deleting the CSScriptNpp folder and CsScriptNpp.dll and reinstalling from the 7z file, but I'm still getting the exception.
Aug 25, 2014 at 3:46 AM
>but says it can't download the binaries and redirects me to the Codeplex page
I means downloading programmatically is not possible for whatever reason. It is in fact expected that some environments may prevent downloading, that is why you are redirected to the Download Page. Thus you need to do the manual download. This is what you did.

>I downloaded the 7z file and unzipped into the Plugins folder, but now when I start NPP I get an "Unknown Exception" dialog,
Yes this is exactly what you should do. The exception means that something prevents the plugin from starting. What exactly....?

I just tried on a clean virtual "Win7 Ultimate x32, Npp-v6.6.8, UAC-enabled" and everything seems OK. I was able to upgrade from AboutBox and manually by removing all binaries and copying all new binaries from the manually downloaded 7z.

I also tried the same on "Win8.1 Pro x64 with Npp v6.6.8 and UAC-disabled".

It looks like you have something in your environment that prevents a proper plugin deployment.

Unfortunately the best way to so investigate is to debug the plugin loading sequence but I am not sure you are comfortable with that.
Though you can do a few simple steps to investigate the issue.
  1. Remove the plugin completely.
  2. Install v1.0.30.0. We know for sure it works.
  3. Substitute CSScriptNpp.dll with it's v1.0.31.0 equivalent.
This should fix it as the only difference between these DLLs is that they map NPP menu item action differently. If it doesn't then CSScriptNpp.dll is an "offender". If it does then most likely your first v1.0.31.0 manual file copying did not produce the correct deployment.
Aug 25, 2014 at 4:54 PM
The issue was that the files in the 7z are "blocked" by Windows after being downloaded. When I unblocked the 7z file before unzipping to the plugins dir, .31 worked just fine. (Alternatively, unblocking all of the files after unzipping worked, as did just installing from the MSI.)

Thanks for your help.
Aug 26, 2014 at 6:39 AM
I really appreciate you sharing this last bit of the information.

I knew that Windows locks Zip file content if it was downloaded from the Internet. And that is the reason why I started packing the binaries with 7z. It worked so far but your report indicates that 7z is not fully immune.

What was the application that you used to unpack 7z? It seems that right-click and '7z->Extract to...' does not lock the files.
Aug 26, 2014 at 12:45 PM
I used WinZip. If you were using the 7zip application, my guess is that it unblocked the files behind the scenes, but that's not behavior that you can count on. (And of course this isn't specific to zip/7z files; all downloaded files are marked as blocked, but that has different effects depending on what kind of file it is and what application the file is used with.)
Aug 26, 2014 at 1:18 PM
Yeah, that is why I stopped using WinZip and switched to 7zip.

The reason is simple: 7zip has full integration with the OS but it does not follow the Windows approach with silent locking all extracted executables while WinZip does. On windows executables are any .exe, .dll and *.chm.

Though I didn't know WinZip now supports 7z. Supports and 'breaks' via file locking.

I have placed the warning on the 'download page' to help others to avoid your pain.

Thank you for your feedback.
Jan 29, 2015 at 12:59 PM
Edited Jan 29, 2015 at 12:59 PM
Hello, I have another sort of problem, debugging works fine for simple scripts (like "hello world" from samples), but when I tried to debug more complex script I have no breakpoints hits.

Some description of my environment:

Windows 7 Ultimate, x64, UAC enabled
Notepad++ 6.7.4
CS-Script NPP Plugin 1.0.38

"Complex" script means that it has some references to custom assemblies and one cs-script file, everything compiles and works fine, but without debugging.

My guess, maybe the reason is platform-host x86 script settings ?

Brief listing of my script:
//css_dbg /platform:x86;
//css_host /platform:x86;
//css_include BacktesterScript.cs // Path added to SearchDirs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using UberQuant.Backtester; // Path added to SearchDirs
using System.IO;

namespace test

    public class Script
        static void Main(string[] args)
            string enginesettings = "GLOBAL_NG";
            string analysismode = "Backtest";

            var settings = BacktesterScript.LoadSettings(enginesettings);
            BacktesterScript.DOTest(new TestSystemClass(), settings, analysismode);
Jan 31, 2015 at 3:28 AM
In this case the problem is something rather expected. The script execution in your case is hosted not by cscs.exe but by a surrogate host processes and Npp debugger only knows how to debug cscs.exe. You can still place the assertion execute the script without the debugging and attach the debugger (either Npp or VS) when the assertion pops up.

Though I am currently working on allowing Npp debugger to start the surrogate process similar to cscs.exe.
Feb 1, 2015 at 7:55 AM
Done. The latest Release v1.0.39.0 supports debugging surrogate script hosts.
Mar 6, 2015 at 7:25 PM
It seems that the best version of this plugin is the 1.0.30. elegant,simple and it works fine I tested it with this
using System;
using System.Diagnostics;

namespace t {
public class Program {
    static public void Main(string [] args) {
        Console.WriteLine("Starting the code");
        test t = new test();
        int x = 3, y = 2;
        t.divide(x, y);

public class test {
    public void divide(int a, int b)
        int x = Factorial(a);
        int result = x /b;
        Console.WriteLine("The result: {0}", result);

    public int Factorial(int n)
         if (n <= 1)
            return 1;
        return n * Factorial(n - 1);

Where I used some complex staff more than call the console and the debugger just work fine F9 to set the breakpoint and then press ALT+F5
for the newer versions including the latest one it's just a useless piece of code (sorry to say that oleg_s because I really appreciate this plugin!), in deed for the letest one 1.0.4 when you try to build the script a messagebox appears with the message could not load script so it doesn't work at all neither for executing nor for debugging

So to resume the is the best version until now.
For the instance, I suggest you to make some investigations about scriptcs try to have a look on you may add an option to start toy with .csx scripts
Finally I would to thank you again oleg_s for this pluggin and keep the god work
Mar 11, 2015 at 5:18 AM
Edited Mar 13, 2015 at 12:58 AM
I am sure it is frustrating for you but it is close to impossible for me to help you with the amount of information you provided so far.

I have tested your script on two PCs (Win8/x64 and Win7/x86) with the latest version of the plugin (v1.0.40) and in both cases it loaded correctly and both F9 and Alt+F5 worked as expected. Thus the problem is somehow caused by your environment conditions or specific to your depployment. Please let me know some details of your environment (OS, CS-Script presence...), possible the screenshot of the error message... And I will guide you through. I am sure we will sort it out.

You may also want to post in a new thread as this one is dedicated to two very specific topics:
  1. The deployment problem caused by the Windows security policy
  2. Feature request for debugging x86 scripts on x64 OS

When testing I noticed that on Win7/x86 the first break current step line marker wasn't displayed properly but the next step (F10) fixes the problem. Most likely it is caused by different behavior of MDbg.exe on this OS (current step info isn't sent in the right order). While this problem is not related to the one you are experiencing I will investigate it further.
Mar 12, 2015 at 6:36 PM
Ok I'm absolutely agree, I'will post a video in my video channel so that you can see what's happens and you can locate exactly what the problem is, I will do this video as soon as possible

Mar 15, 2015 at 4:35 PM
I just reinstall it in my 64 bits windows server 2008 r2 machine and it works now, but sometimes it stops debugging so I reinstall it again, I also tested it in ubuntu 64 bits and opensuse 64 bit and it works with wine
Mar 16, 2015 at 12:27 AM
Thank you for letting me know.
Current step line marker rendering problem may be interpreted as "sometimes it stops debugging" (it is fixed in the build for the release scheduled for this week) but of course I cannot say this for sure.

The fact that it works on Ubuntu via Wine is rather intriguing. I use CS-Script on raw Linux, it's not a problem. And I know that N++ can be run on Wine but I was almost certain that any managed plugin for N++ would fail on Wine. And to have MS debugger (mdbg.exe) working there is almost like a si-fi news. But a good one :o)

Can you please confirm that we are talking about the same things here. You did successfully run and debug C# script(s) in Notepad++ with CS-Script plugin on Ubuntu/Wine, didn't you?