That seems to be a bug in the CopyToGD() method.

It can load the png you write to disk without error.

It can also successfully create a GD image from the data returned by the SaveToData() method:

use Win32::API;
use Win32::GUI::DIBitmap;
use GD;

$GetDC      = new Win32::API('user32','GetDC',['N'],'N');

my $dc      = $GetDC->Call(0);
my $dib     = newFromDC Win32::GUI::DIBitmap ($dc);

$dib->SaveToFile("DIBitmap.png");

#my $GDimage = GD::Image->newFromPng( "DIBitmap.png", 1 );

my $mem = $dib->SaveToData( Win32::GUI::DIBitmap::GetFIFFromFormat( 'P
+NG' ) );
my $GDimage = GD::Image->newFromPngData( $mem, 1 );

open (DISPLAY, ">GD.png");
binmode DISPLAY;
print DISPLAY $GDimage->png;
close (DISPLAY);
[download]

You should raise a bug report with the author.

The problem probably stems from the mismatch between the version of the GDImageStruct used by DIBitmap & the version used by the latest GD incarnations:

Compare: (<)C:\test\GDstruct.gd (3146 bytes)
   with: (>)C:\test\GDstruct.dib (3124 bytes)

63,67c63
<     /* There should NEVER BE ACCESSOR MACROS FOR ITEMS BELOW HERE, s
+o this
<        part of the structure can be safely changed in new releases. 
+*/
< 
<     /* 2.0.12: anti-aliased globals. 2.0.26: just a few vestiges aft
+er
<       switching to the fast, memory-cheap implementation from PHP-gd
+. */
---
>     /* 2.0.12: anti-aliased globals */
71a67,78
>     unsigned char **AA_opacity;
>     int AA_polygon;
>     /* Stored and pre-computed variables for determining the perpend
+icular
>        distance from a point to the anti-aliased line being drawn: *
+/
>     int AAL_x1;
>     int AAL_y1;
>     int AAL_x2;
>     int AAL_y2;
>     int AAL_Bx_Ax;
>     int AAL_By_Ay;
>     int AAL_LAB_2;
>     float AAL_LAB;
79,82d87
< 
<     /* 2.1.0: allows to specify resolution in dpi */
<     unsigned int res_x;
<     unsigned int res_y;
84,85d88
<   
<
[download]