[Solved] Q: Debug a plugin DLL - can we do OutputDebugstring to the event log?

[d7_2_laz]

After some initial hurdles basically i got debugging a Notepad++ plugin DLL (here: a demo template) to work.

But stumbled across two questions. The first one here:

Code: Pascal  [Select][+][-]

1. procedure THelloWorldDockingForm.FormCreate(Sender: TObject);
2. ...
3. begin
4.    Outputdebugstring(pchar('THelloWorldDockingForm.FormCreate' ));

No output within the event log. Is this normal when debugging a (plugin) DLL?

Debug backend is gdb.

[Martin_fr]

Simplest way is to try it.

I would guess that it will work (if it works from a normal app, which iirc it does / but I don't remember when I last used it).

After all, this goes to the windows api, and the windows api sends it to an attached debugger. Debuggers (incl gdb) attach to a process. So main program or dll should not matter, all the same process.

If an app launches a child process, then probably not. Threads likely yes.


Support for non ascii depends on the debugger. And using the W version of the function.

[d7_2_laz]

Had tried it, no intended output (differently to normal windows apps, where i use it punctually for to gather some information quickly).

Where gdb (via project options) is a bit more talkative than fpdebug here, at least it says some lines more (see image), but not the content i wrote in 'FormCreate'.

The image tells also about the host process (notepad++.exe), and maybe the message would be routed to that one?

Btw, due to the line: 'Debug output:' (empty) : for to exclude it comes from me, but is empty due to a missing W-version of OutputDebugString  (which accepts only PChar), i repeated the directive 4 times, but there was always only one empty line in the output. So that line comes from a different source.

Edit:
Oh, there's really a W-version for OutputDebugString (didn't know that yet);

Code: Pascal  [Select][+][-]

1.    OutputDebugStringW(LPCWSTR(' THelloWorldDockingForm.FormCreate   ' ));

but it doesn't create a different output here, and in my string are not non-ascii chars.

[Martin_fr]

You can check what gdb actually gets, versus what the IDE reports.
Menu: view > ide internals > debug output.

Has all the data exchanged with gdb.

I don't know if (and if then from which version on) gdb would get the "W" texts.

A debugger must tell Windows if it can handle those. If it can't, I am not sure if it gets nothing, or some translations, or.....
And obviously I don't know gdb internals. I don't know if it reads the W version.

IIRC I added the W version to fpdebug.

But I don't use that myself, so it got a few tests when added, and that is it.

If it has a bug, then I would appreciate if you have an easy way to reproduce and report it on the bug tracker.
Ideally not requiring notepad++, but have app and dll to be pascal code.

Though I can't promise how soon I can get to that. Very busy right now.

[440bx]

@d7_2_laz

see what you get using sysinternals DebugView.

You can download it from https://learn.microsoft.com/en-us/sysinternals/downloads/debugview

HTH.

[d7_2_laz]

@Martin_fr:
Thank you kindly for your understanding!
Of course i'd regret when not being able to employ this useful little helper from within the app's code lines, ,complementing the capabilties of the debugger itself
Nevertheless i'd not call it a bug .... because i really don't know whether it's foreseen to be part of the scope of OutputDebugView to support DLLs.

If any opinion here should come up, i'd be happy to provide a self-containing example (containing also a portable notepad++, with all config), where out-of-the-box one could reproduce by click-and-play (unzip, dblclick on the lpi, compile, Run and see the eventlog) without taking care about downloading and adapting internal paths.
Precondition would be only: we agree on a certain root path (eg. D:\_test_nppPlugin), so that no adaptions would be needed to be done.
Size approx. 14,5 MB (due to the size of the NPP host application; portable version; size already reduced by removing most of the localization files)).
But there should be a decision: should we support or not?

Origin of the demo: rdipardo's 'Notepad++ Plugin Template for Delphi & Lazarus':
https://bitbucket.org/rdipardo/delphiplugintemplate/src/default/Readme.textile
Some of (imo) strange phaenomenoms of the demo i'd already addressed on the Notepad++'s plugin side, or will do so within the new Wiki from rdipardo.
I needed only a few minutes to make the demo initially work with Lazarus; with Delphi, i'd assume, if should be done fast too.
And this could be interesting too: to verify: does (newest) Delphi support this (OutputDebugView from within a DLL)?

@440bx
Oh yes, the good old DebugView, i  remember .... thank you for the hint!
I'm a bit sceptical, looking onto the supported OS versions (no Win 10) as well as the sentence "will captute Win32 OutputDebugString" etc.
I tried with Delphi 7 (32bit) via an old plugin DLL (from 2013) and from within and exe. But i could not see output. I remember ages ago (Windows XP) i had one though.
Sad .. would be nice to be able to use DebugView for this purpose .. but maybe i do something wrong.

[Martin_fr]

Well, I don't see, why it shouldn't work in a dll. Have you tried that the same OutputDebugView  works in a normal app?

Have you checked, if it is included in the "Debug output" of the "Ide Internals" (and does not get lost at some later stage...).

Also, I don't know what OutputDebugView maps to: OutputDebugViewW or OutputDebugViewA.
Try either of them explicitly.
Maybe only one is supported.

[d7_2_laz]

"works in a normal app?"    -> Yes, works very fine here  ... // "OutputDebugString" (*)

"if it is included in the "Debug output" of the "Ide Internals"  -> still my Todo, sorry!

"Try either of them explicitly"    -> tried both at the same place. Both work from within the exe, but not from within a DLL (the demo DLL)

(*) Edit: the "DebugView" app from sysinternals v4.90 didn't work for me here at all, neither 32bit version (with Delphi 7)  or 64bit version w. Lazarus 3.6 64 bit. On Win 10. - Hopefully i did nothing wrong.
Remember roughly it worked together with Delphi7 on an older OS (XP).

[Martin_fr]

I just wrote a test library, and a test pascal program.

I tested
- with the function used via "external ... name", and with OpenLibrary/GetProcAddress.
- FpDebug and gdb 7.9.1
- W/A versions

I got the output of all calls, from within the library and the main app.

Tests performed on Win-10 / 64 bit / 64bit Lazarus and 64 bit program.

Lazarus 4.0RC

-------------------

So I don't know why it does not work for you.

I don't know if notepad++ does something....

Have you made sure, that the code in your library is executed ?
E.g., if you replace it by

Code: Pascal  [Select][+][-]

1. PByte(0)^:=1;

Do you get a crash?

[d7_2_laz]

These are very very interesting points Martin. And the question ('the code in your library is executed ?') might sound trivial, but i fear in fact it is not.
It touches a chapter that was unclear for me since the beginning i deal with this plugin demo:

- Given, Npp is installed or unzipped into <npp-dir>.
- Npp expects the plugin to exist in/as:  <npp-dir>\plugins\<plugin-name>\<plugin-name>.dll
  If not at least one copy of the dll does exist here following this rule, the plugin won't never be visible in the Npp menu.
- We can set a 'host application' to <npp-dir>\Notepad++.exe
- But what is 'Working directory' here?  <npp-dir>, or <npp-dir>\plugins (because Npp might extend that implicitely to the correct path, given by the dll's name?)
  Or to (fully extended:) <npp-dir>\plugins\<plugin-name>  ?
-> Wherefrom should the debugger know, where Npp does expect the dll?  -> no chance
-> Wherefrom should Npp know, where Lazarus compiles? -> no chance

The solution: the compiler option 'Target-filename (-o)' must be set to <npp-dir>\plugins\<plugin-name>\$NameOnly($(ProjFile))

And so - see image.

Hard lessons learnt: (was everybody reading really fully aware of it? Me not .....)
If a DLL plugin should be debugged (or OutputDebugString used), it's not sufficent to set 'host application' (and maybe working-dir).
It MUST be assured that the path of the compiler output physically is the same where the host application does expect the plugin to exist.
Well-known to all except me?

Could be noted in the documentation ...